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ABSTRACT 


This  thesis  concerns  the  effective  and  safe  software  reuse  in  safety-critical 
system-of-systems.  Software  reuse  offers  many  unutilized  benefits  such  as  achieving 
rapid  system  development,  saving  resources  and  time,  and  keeping  up  technologically  in 
an  increasingly  advancing  global  environment.  System  software  needs  to  be  designed  for 
both  reuse  and  safety,  and  available  information  needs  to  be  shared  effectively.  We 
introduce  a  process  neutral  framework  for  software  reuse  in  safety-critical  system  of 
systems.  That  framework  consists  of  four  elements:  organizational  factors,  component 
attributes,  component  specification,  and  safety  analysis.  We  developed  a  model  (C^RA) 
to  capture  the  relevant  component  information  and  assist  in  specification  matching.  We 
conducted  a  survey  of  software  safety  metrics,  created  metrics,  and  developed  a  ranking. 
We  then  applied  the  framework  utilizing  the  reuse  of  a  generic  avionics  software 
component.  Our  key  findings  are  that  congruence  between  all  elements  is  required; 
software  should  posses  certain  attributes  with  metrics  that  support  a  safe  design;  software 
component  information  can  be  specified  using  C^RA;  and  a  process  identified  a  system- 
of-systems  hazard  analysis  for  software  reuse.  The  framework  outlined  provides  a 
solution  that  enables  effective  software  reuse  in  safety-critical  system  of  systems. 
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I.  INTRODUCTION 


A,  THE  EVOLUTION  OF  SOFTWARE  REUSE 

Software  reuse  evolved  from  rudimentary  techniques,  such  as  development  of 
function  calls  in  early  programming  languages  (e.g.,  FORTRAN)  and  libraries  of 
software  routines  for  performing  scientific  calculations,  to  modern-day  approaches  to 
reuse  that  cover  the  entire  software  lifecycle  and  all  software  system  artifacts.  For 
instance,  there  are  now  well  established  methods  for  reusing  software  architectures  and 
design  patterns.  The  inclusion  of  high-level  artifacts  such  as  use  cases  and  requirements 
has  been  in  part  due  to  the  realization  that  decisions  made  early  in  the  development 
process  typically  have  a  significant  impact  on  software  engineers’  ability  to  refine  the 
these  artifacts  into  a  machine  interpretable  or  executable  system.  Software  reuse  relies  on 
preplanning  to  enact  a  sustainable  reuse  program  that  meets  the  needs  of  the 
organizations  involved  in  a  system  development  project.  Preplanning  distinguishes 
software  reuse  from  software  salvage,  an  unsystematic,  opportunistic  approach  to  using 
software  system  artifacts  not  developed  with  reuse  in  mind. 

Another  driver  for  continued  innovation  in  software  reuse  is  what  has  been 
referred  to  as  the  “software  crisis”^:  the  imbalance  between  the  explosive  growth  in 
software  demand  and  both  lagging  software  development  productivity  and  the  shortage  in 
the  supply  of  software  professionals.  This  “software  crisis”  is  just  as  apropos  today  as  it 
has  been  over  the  past  forty  years  of  software  engineering.  The  success  rate  of  delivering 
or  maintaining  information  systems  on  schedule,  at  cost,  and  within  performance 
constraints  has  not  improved  since  the  1970s,  as  evidenced  by  the  results  of  studies 
reported  by  the  U.S.  Government  Accountability  Office  and  the  Standish  Group.  When 
applied  in  an  appropriate  manner,  software  reuse  provides  a  means  for  improving 
software  quality,  increasing  development  productivity,  shortening  time-to-market  (i.e., 
creating  competitive  advantage),  achieving  consistent  application  functionality,  reducing 

1  NATO  Software  Engineering  Conferenee,  NATO  Seienee  Committee,  Garmiseh,  Germany,  7-11 
Oetober  1968. 
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risk  of  cost  and  schedule  overruns,  improving  validation  of  user  requirements  through 
prototyping,  leveraging  of  technical  skills  and  knowledge,  and  avoiding  the  inclination  to 
“reinvent  the  wheel”  (e.g.,  a  survey  performed  in  1983  found  that  85%  of  software 
developed  was  not  unique^). 

In  2003,  U.S.  Department  of  the  Navy  adopted  an  open  arehitecture  initiative^  to 
realize  some  of  the  aforementioned  improvements  in  software  development.  The  Navy’s 
open  arehitecture  is  a  multi-faceted  strategy  providing  a  framework  for  developing  joint 
interoperable  systems  that  adapt  and  exploit  open-system  design  principles.  This 
framework  includes  a  set  of  principles,  processes,  and  best  praetiees  that:  provide  more 
opportunities  for  competition  and  innovation;  rapidly  field  affordable,  interoperable 
systems;  minimize  total  ownership  cost;  optimize  total  system  performance;  yield 
systems  that  are  easily  developed  and  upgradeable;  and  aehieve  component  software 
reuse.  Thus,  there  is  a  reeognized  need  to  aehieve  greater  software  component  reuse, 
whieh  will  subsequently  support  the  achievement  of  other  outeomes  of  the  Navy 
initiative.  There  is  also  the  need  to  avoid  software  duplication,  save  resources,  and  get 
more  out  of  existing  resources  to  keep  Navy  and  the  other  U.S.  services  positioned  as  the 
best  in  the  world  at  an  aceeptable  eost. 

Without  software  reuse,  it  is  unlikely  that  an  organization  will  achieve  a 
technological  advantage  or  be  at  the  eutting  edge  of  technology  development  beeause  it 
will  simply  take  too  long  or  be  too  costly  to  achieve  that  position  via  either  green-fields 
development  (i.e.,  starting  from  scrateh)  or  software  salvage. 

Although  the  rationale  for  software  reuse  is  sound,  there  are  signifieant  challenges 
to  applying  reuse  in  the  development  of  safety-critieal  applications  in  a  system  of 
systems.  A  system  of  systems  is  an  amalgamation  of  legacy  systems  and  developing 
systems  that  provide  an  enhanced  eapability  greater  than  that  of  any  of  the  individual 


2  E.J.  Joyce.,  Reusable  Software:  Passage  to  Productivity.  Datamation,  Volume  34,  Number  18, 
Spetember  15,  1988,  p.  98. 

3  Department  of  Defense  Directive  5000.1,  The  Defense  Acquisition  System,  12  May  2003. 
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systems  within  the  system  of  systems.^  System  of  systems  are  a  great  departure  from 
standalone  systems.  There  is  uncertainty  and  risk  associated  with  assumptions  about  the 
interfaces  between  the  component  systems  and  issues  of  system  interoperability.  Also 
certain  rules  and  restrictions  apply  to  the  reuse  of  software  in  safety  critical  systems. 
Planning  for  reuse  and  determining  the  appropriateness  of  reuse  in  a  safety-critical 
system  of  systems  represent  a  significant  challenge  because  of  the  large  number  of 
potential  system  configurations,  their  non-stationary  position,  the  associated  emergent 
hazards,  and  derived  safety  requirements.  Furthermore,  safety  is  a  system  property  and 
thus  reused  software  will  impact  on  the  system  safety. 

There  are  also  challenges  associated  with  using  non  developmental  items  (NDIs) 
in  a  system  of  systems.  The  challenges  arise  because  a  single  stakeholder  does  not  control 
these  individual  systems  and  these  systems  may  be  used  in  plug-and-play  arrangements, 
leading  to  multiple  possible  configurations,  which  will  result  in  emergent  safety 
properties  and  requirements. 

Overcoming  the  reusability  challenges  means  that  more  software  will  be  reused, 
software  development  productivity  will  increase  and  the  quality  of  the  software  and 
system  will  improve.  Even  after  applying  these  rules  you  do  not  necessarily  have  a  safe 
design,  because  even  the  best  design  cannot  fully  isolate  the  safety  critical  functionality 
from  the  reused  component  or  non-developmental  item.  This  currently  limits  the  extent 
that  software  can  be  reused  in  safety-critical  systems,  including  that  in  a  system  of 
systems.  A  software  component  that  possesses  certain  essential  attributes  that  are 
explicitly  revealed  and  is  classified  appropriately  will  be  more  readily  available  for  use 
and  reuse  in  a  safety-critical  system  of  systems.  A  framework  describing  these  software 
component  requirements  will  facilitate  effective  reuse  in  safety-critical  system  of 
systems,  creating  advantages  for  both  the  U.S.  and  Australian  defense  communities  in 
developing  safety-critical  systems.  Many  military  systems  today  are  both  safety  critical 
and  composed  of  legacy  and  new  development  systems,  such  as  the  U.S.  Ballistic  Missile 
Defense  System. 

4  D.S.  Caffall.,  J.B.  Michael.,  Architectural  Framework  for  a  System-of-Systems,  in  Proc  of  the  IEEE 
International  Conference  on  Systems,  Man  and  Cybernetics,  Volume  2,  10-12  Oct  2005,  pl876. 
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B, 


CONCEPTS  AND  DEFINITIONS 


1.  Software  Reuse 


Software  reuse  is  the  use  of  existing  software  artifacts  in  the  development  of  other 
software  artifacts  with  the  goal  of  improving  productivity  and  quality,  among  other 
factors.^  Software  reuse  can  also  be  described  as  the  process  of  leveraging  components 
from  one  system  or  environment  for  use  in  other  systems  or  environments  with  no  or 
minimal  change  to  the  component.  Environment  in  this  case  refers  to  the  context  of  use  of 
the  system,  such  as  the  classic  example  of  reusing  the  guidance  and  control  software  from 
Arianne  4  in  Arianne  5  or  the  case  of  software  evolution,  where  the  requirements  and 
context  of  a  system  changes  with  changes  in  its  mission.  Software  reuse  differs  from 
software  salvage  in  that  it  occurs  in  a  systematic  way  with  a  degree  of  preplanning  for 
future  use.  Software  reuse  results  from  effective  foresight  during  development,  providing 
an  investment  in  that  future  use.  Conversely,  software  salvage  is  an  unsystematic 
opportunistic  approach  to  using  software-system  artifacts  that  were  not  developed  with 
reuse  in  mind.  Software  artifacts  are  the  products  or  byproducts  of  the  software 
development  process  that  comprise  possible  candidates  for  reuse.  Lim  identifies  ten  types 
of  software  artifacts  that  may  be  reused.  They  are: 


1 .  Architectures 

2.  Source  Code 

3.  Data 

4.  Designs 

5.  Documentation 


6.  Estimates 

7.  Human  Interfaces 

8.  Plans 

9.  Requirements 

10.  Test  Cases 


According  to  Eim,  a  software  component  is  a  set  of  software  artifacts  that 
comprise  a  coherent  module.  It  may  contain  many  of  the  artifacts  described  above. ^ 
There  are,  however,  many  different  definitions  for  a  software  component.  Braude  defines 
a  software  component  as  a  software  collection  used  without  alteration,  under  the  goal  of 


5  W.C.  Lim.,  Managing  Software  Reuse,  A  Comprehensive  Guide  to  Strategieally  Reengineering  the 
Organization  for  Reusable  Components,  Upper  Saddle  River,  NJ.:  Prentiee  Hall  PTR,  1998,  p7. 

6  W.C.  Lim.,  Managing  Software  Reuse,  A  Comprehensive  Guide  to  Strategieally  Reengineering  the 
Organization  for  Reusable  Components,  Upper  Saddle  River,  NJ.:  Prentiee  Hall  PTR,  1998,  p539. 
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reuse  and  as  the  vehicle  for  delivering  reused  Alternatively,  Larman  states  that  a 
component  represents  a  modular  part  of  a  system  that  encapsulates  its  contents  and  whose 
manifestation  is  replaceable  within  its  environment.^  Pressman,  on  the  other  hand, 
defines  a  software  component  as  a  unit  of  composition  with  contractually  specified  and 
explicit  context  dependencies  only.^  Although  there  may  be  many  different  definitions, 
there  is  much  commonality  among  them.  In  this  thesis  we  define  a  software  component 
as  a  collection  of  software  comprising  a  module  with  a  well-defined  purpose  that  may  be 
used  with  no  or  minimal  alteration. 

Lim  identifies  the  many  benefits  of  software  reuse  as: 

•  Improved  software  quality 

•  Increased  development  productivity 

•  Shortened  time  to  market 

•  Consistent  application  functionality 

•  Reduced  risk  of  cost  and  schedule  overruns 

•  Allows  prototyping  for  validating  user  requirements 

•  Leveraging  of  technical  skills  and  knowledge 

Software  reuse,  once  established,  enables  an  organization  to  accomplish  more 
without  additional  resources.  This  is  important  for  both  businesses  trying  to  gain  and 
maintain  a  competitive  advantage  and  public  sector  entities  attempting  to  acquire  the  best 
systems  at  the  least  cost.  Software  reuse  allows  an  organization  to  generate  competitive 
advantage  and  to  avoid  duplicating  past  efforts.  Furthermore,  it  is  one  method  for 
mitigating  the  software  crisis.  Software  reuse  is  a  means  for  an  organization  to  leverage 


7  E.  Braude.,  Software  Design:  From  Programming  to  Architecture,  Hoboken,  NJ.:  John  Wiley  & 
Sons,  2004,  p385. 

8  C.Larman.,  Applying  UML  and  Patterns,  An  Introduction  to  Object-Oriented  Analysis  and  Design 
and  Iterative  Development,  Third  Edition,  Upper  Saddle  River,  NJ.:  Pearson  Education,  2005,  p654. 

9  R.S.  Pressman.,  Software  Engineering  A  Practitioner’s  Approach,  Sixth  Edition,  New  York,  NY.: 
McGraw-Hill,  2005,  p817. 

10  W.C.  Lim.,  Managing  Software  Reuse,  A  Comprehensive  Guide  to  Strategically  Reengineering  the 
Organization  for  Reusable  Components,  Upper  Saddle  River,  NJ.:  Prentice  Hall  PTR,  1998,  pl02. 
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past  successes  through  organizational  learning  and  institutional  memory.  Software  reuse 
represents  a  strategy  for  meeting  the  ehallenges  of  a  rapidly  changing  complex 
environment. 

These  benefits,  however,  may  not  be  realized  if  reuse  is  not  implemented 
effectively.  For  example,  reusing  a  software  component  that  subsequently  does  not  meet 
the  requirements,  which  may  not  be  evident  until  verification  and  validation  activities, 
may  involve  increased  work  and  costs  because  new  software  may  be  developed  later  than 
originally  intended.  Without  organizational  support  for  reuse,  including  incentives  for 
reuse,  these  benefits  may  be  overlooked  and  go  largely  unrealizable. 

2.  System  Safety 

Safety  is  defined  as  freedom  from  those  conditions  that  can  cause  death,  injury, 
oeeupational  illness,  damage  to  or  loss  of  equipment  or  property,  or  damage  to  the 
environment.  1 1 

In  other  words,  safety  is  freedom  from  eonditions  that  eause  aceidents  (mishaps). 
Furthermore,  safety  is  the  execution  of  a  software  produet  in  a  system  without  causing 
the  system  to  exist  in  a  hazardous  state.  12 

MIL-STD-882Ddefines  system  safety  as: 

the  application  of  engineering  and  management  principles,  criteria,  and 
techniques  to  achieve  aceeptable  mishap  risk,  within  the  eonstraints  of 
operational  effeetiveness  and  suitability,  time,  and  cost,  throughout  all 
phases  of  the  system  life  cycle, 

Furthermore,  MIL-STD-882D  defines  system  safety  engineering  as: 

An  engineering  discipline  that  employs  speeialized  professional 
knowledge  and  skills  in  applying  seientific  and  engineering  principles. 


11  Department  of  Defense,  Standard  Praetiee  for  System  Safety,  MIL-STD-882D,  10  February  2000. 

12  R.  Singh.,  A  Systematie  Approaeh  to  Software  Safety,  in  Proe  of  the  sixth  Asia  Paeifie  Software 
Engineering  Conferenee  (APSEC  ’99),  1999. 

13  Department  of  Defense,  Standard  Praetiee  for  System  Safety,  MIL-STD-882D,  10  February  2000. 
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criteria,  and  techniques  to  identify  and  eliminate  hazards,  in  order  to 
reduce  the  associated  mishap  riskd^ 


In  these  cases  MIL-STD-882D  defines  a  hazard  as: 

Any  real  or  potential  condition  that  can  cause  injury,  illness,  or  death  to 
personnel;  damage  to  or  loss  of  a  system,  equipment  or  property;  or 
damage  to  the  environment, 

A  hazard  can  also  be  defined  as  a  source  of  potential  harmi^  or  a  prerequisite  to  a 
mishap  or  accident. 

The  system  safety  process  is  a  specific  application  of  the  risk  management 
process  to  the  system  safety  domain  where  instead  of  risk,  the  terms  hazard  and  mishap 
risk  are  used.  The  objective  of  system  safety  is  to  achieve  an  acceptable  mishap  risk 
through  a  systematic  approach  of  hazard  analysis,  risk  assessment,  and  risk 
management.!^  Figure  1  illustrates  the  risk  management  process  as  defined  in  the 
Australian  and  New  Zealand  standard  AS  4360.!* 


14  Department  of  Defense,  Standard  Practice  for  System  Safety,  MIL-STD-882D,  10  February  2000. 

15  Department  of  Defense,  Standard  Practice  for  System  Safety,  MIL-STD-882D,  10  February  2000, 

p2. 

16  AS/NZS  4360:2004.  Australian  /  New  Zealand  Standard.  Risk  Management,  p3. 

17  Department  of  Defense,  Standard  Practice  for  System  Safety,  MIL-STD-882D,  10  February  2000, 
p3. 

18  AS/NZS  4360:2004.  Australian  /  New  Zealand  Standard.  Risk  Management. 
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COMMUNICATE  AND  CONSULT 


Figure  1.  AS/NZS  4360:2004  Risk  Management  Proeess  Overview 
The  system  safety  proeess  as  defined  by  MIL-STD-882D  is  as  follows: 
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Documentation  of  the  System  Safety  Approach 


Identification  of  Hazards 


_ I _ 

Assessment  of  Mishap  Risk 


_ * _ 

Identification  of  Mishap  Risk 
Mitigation  Measures 


Reduction  of  Mishap  Risk  to  an 
Acceptable  Level 


\'erification  of  Mishap  Risk  Reduction 


_ T _ 

Resiew  of  Hazards  and  Acceptance  of  Residual 
Mishap  Risk  by  the  Appropriate  Authority 


_ S _ 

Tracking  of  Hazards,  their  Closures,  and 
Residual  Mishap  Risk 


Figure  2.  MIL-STD-882D  System  Safety  Process 

Both  processes  are  similar,  involving  a  number  of  common  steps.  Neither  process 
has  a  way  of  guaranteeing  that  all  relevant  risks  or  hazards  will  be  identified,  which  is 
why  sub-processes  are  required  to  ensure  that  those  relevant  risks  or  hazards  are 
identified  so  they  can  be  treated. 

3,  Software  Safety 

The  discipline  of  software  safety  engineering  is  the  systematic  approach  to 
identifying,  analyzing,  and  tracking  software  mitigation  and  control  of  hazards  and 
hazardous  functions  (e.g.,  data  and  commands)  to  ensure  safer  software  operation  within 
a  system. 


19  Overview  of  Software  Safety,  NASA  Software  Safety,  May  2007,  http://sw- 
assurance.gsfc.nasa.gov/disciplines/safety/index.php. 
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Software  system  safety  is  a  subset  of  system  safety  and,  aceording  to  Leveson, 
“implies  that  the  software  will  exeeute  within  a  system  context  without  contributing  to 
hazards. ”20  Software  safety  is  a  discipline  within  system  safety  engineering  that  focuses 
on  the  system’s  software  and  its  interactions  with  the  hardware  and  human  operators. 
Software  itself  cannot  cause  harm,  except  possibly  emotional  harm  or  stress  (nerves)  to 
those  involved  in  its  development;  however,  through  its  interactions  with  hardware  it  can 
cause  hazards  that  may  result  in  mishaps.  Software  safety  is  an  engineering  and 
management  approach  to  ensuring  that  the  software  minimizes  the  system  safety  risk  to 
an  acceptable  level  while  maintaining  the  effectiveness  of  the  software  and  system.  It  is 
focused  on  meeting  safety  requirements.  The  purpose  of  system  safety  and  software 
safety  is  to  identify  and  mitigate  hazards  associated  with  the  operation  and  maintenance 
of  the  system  and  software  respectively  and  to  define  the  residual  risk,  based  on  success 
of  the  controls  implemented.21 

Software  safety  is  concerned  with  both  removing  defects  in  software  artifacts  for 
which  there  would  be  hazardous  consequences  and  ensuring  the  system’s  specification 
adequately  captures  the  safety  requirements.  Software  safety  is  an  ongoing  process  as  the 
software  and  operational  environment  evolves. 

4,  Safety  Critical  Software 

Safety  critical  is  a  term  applied  to  any  condition,  event,  operation,  process,  or 
item  whose  proper  recognition,  control,  performance,  or  tolerance  is  essential  to  safe 
system  operation  and  support  (e.g.,  safety  critical  function,  safety  critical  path,  or  safety 
critical  component). 22 


20  N.  Leveson.,  Safeware:  System  Safety  and  Computers.  Addison  Wesley,  Boston,  1995. 

21  V.  Basili.,  K.  Dangle.,  L.  Esker.,  F.  Marotta.,  Gaining  Early  Insight  into  Software  Safety:  Measures 
of  Potential  Problems  and  Risks,  in  Proe  of  the  Systems  &  Software  Teehnology  Conferenee,  June  2007, 
p3. 

22  Department  of  Defense,  Standard  Praetiee  for  System  Safety,  MIL-STD-882D,  10  February  2000. 
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According  to  NASA, 23  software  is  safety  eritieal  if  it  meets  at  least  one  of  the 
following  eriteria: 

1.  Resides  in  a  safety-critieal  system  (as  determined  by  a  hazard 
analysis)  and  at  least  one  of  the  following: 

a.  Causes  or  eontributes  to  a  hazard 

b.  Provides  eontrol  or  mitigation  for  hazards 

e.  Controls  safety-eritieal  funetions 

d.  Proeesses  safety-eritieal  eommands  or  data 

e.  Deteets  and  reports,  or  takes  corrective  action,  if  the  system 
reaehes  a  speeific  hazardous  state 

f.  Mitigates  damage  if  a  hazard  oecurs 

g.  Resides  on  the  same  system  (proeessor)  as  safety-eritieal 

software 

2.  Proeesses  data  or  analyzes  trends  that  lead  directly  to  safety 
decisions  (e.g.,  determining  when  to  turn  power  off  to  wind  tunnel  to 
prevent  system  destruetion) 

3.  Provides  full  or  partial  verifieation  or  validation  of  safety-eritieal 
systems,  ineluding  hardware  or  software  subsystems. 

A  safety  eritieal  function  is  any  function,  whether  hardware,  software,  operator,  or 
eombination  thereof,  that  direetly  influences  a  hazard  or  hazardous  situation. 
Furthermore,  it  is  any  funetion  whose  improper  functioning  could  result  in  a  hazard  in 
whieh  improper  funetioning  ineludes  failure  modes,  out  of  tolerance  eonditions,  timing 
error  or  problems  (e.g.,  data  lateney),  or  other  errors.24 


23  Overview  of  Software  Safety,  NASA  Software  Safety,  May  2007,  http://sw- 
assurance.gsfc.nasa.gov/disciplines/safety/index.php. 

24  W.C.  Lim.,  Managing  Software  Reuse,  A  Comprehensive  Guide  to  Strategically  Reengineering  the 
Organization  for  Reusable  Components,  Upper  Saddle  River,  NJ.:  Prentice  Hall  PTR,  1998. 
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In  the  context  of  safety  critical  software,  there  is  the  rule  that  reused  software  or 
non-developmental  items  (NDI),  be  it  COTS,  GOTS,  MOTS^s  or  legacy  software,  may 
not  initiate,  sustain,  or  prevent  occurrence  of  a  safety  critical  function  unless  the  NDI  has 
been  evaluated  to  the  same  level  as  a  developmental  software  component.  This  rule 
results  from  the  reality  that  not  enough  information  is  typically  provided  on  reusable 
software  components  and  that  there  is  not  a  standard  or  shared  understanding  to  describe 
what  that  should  be.  Furthermore,  safety  is  a  system  property,  and  thus  reused  software 
will  impact  system  safety;  it  is  dependent  on  the  interfaces  and  interactions  with  the 
system.  Thus,  this  suggests  that  there  will  always  be  a  requirement  for  analysis  of  the 
component  in  its  intended  environment.  This  is  likely  to  involve  operational  testing  and  is 
dependent  on  the  safety  requirements. 

5.  Safety  Critical  Environment 

A  safety  critical  environment  is  an  environment  in  which  there  are  potential 
hazards  or  hazardous  situations  or  where  proper  system  functioning  is  essential  for  safe 
operation. 


6,  System  of  Systems 

A  system  of  systems  is  an  amalgamation  of  legacy  systems  and  developing 
systems  that  provides  an  enhanced  capability  greater  than  that  of  any  of  the  individual 
systems  within  the  system  of  systems. 26  It  represents  a  natural  evolution  from  systems 
and  systems  development  to  now  integrating  several  systems  to  form  a  greater  system  for 
the  accomplishment  of  specific  objectives. 

System  of  systems  represent  a  significant  departure  from  standalone  systems  as 
their  components  are  individual  systems  often  with  a  high  level  of  autonomy  whereas 
system  components,  subsystems  are  often  unable  to  operate  in  isolation  from  the  other 
subsystems  that  compose  the  system.  Furthermore,  system  of  systems  development  is  not 

25  Commercial  off  the  Shelf  (COTS),  Government  off  the  Shelf  (GOTS),  and  Modified  off  the  Shelf 
(MOTS). 

26  D.S.  Caffall.,  J.B.  Michael.,  Architectural  Framework  for  a  System-of-Systems,  in  Proc  of  the  IEEE 
International  Conference  on  Systems,  Man  and  Cybernetics,  Volume  2,  10-12  Oct  2005,  pl876. 
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just  a  larger  version  of  systems  development;  it  represents  an  area  of  greater  uncertainty 
and  risk  associated  with  assumptions  and  unknowns  of  the  interfaces  between  the 
component  systems.  The  component  systems  are  often  developed  to  meet  requirements 
and  constraints  that  are  different  from  those  of  the  system  of  systems.  It  is  often  the  case 
in  system  of  systems  development  that  legacy  systems  are  integrated  with  new  systems 
and  thus  not  all  system  of  systems  components  were  designed  to  optimize  the 
performance  or  dependability  of  the  system  of  systems  or  to  conform  to  required 
interface  and  interoperability  specifications. 

Example  system  of  systems  are  the  U.S.  Ballistic  Missile  Defense  System 
(BMDS)  and  the  U.S.  Army’s  Future  Combat  System  (ECS).  The  U.S.  Commercial  and 
Military  Aviation  systems  could  be  described  as  further  system  of  systems  examples. 

7.  Safety-Critical  System  of  Systems 

A  safety-critical  system  of  systems  is  a  system  of  systems  operating  in  an 
environment  in  which  there  are  hazards  or  hazardous  situations  or  where  proper  system 
functioning  is  essential  for  safe  operation  within  a  system  of  systems.  The  environment 
represents  the  context  in  which  the  system  will  be  used  and  in  the  case  of  a  system  of 
systems,  there  may  be  many  different  contexts  of  use.  These  many  contexts  of  use  will 
have  a  significant  affect  on  safety  because  safety  is  context  dependent.  Safety  is  a 
function  of  the  context  of  use,  against  which  hazards  can  be  identified. 

Commercial  and  military  aviation  could  be  described  as  a  safety-critical  system  of 
systems.  In  the  case  of  commercial  and  military  aviation,  a  number  of  different  systems 
operate  cohesively  for  a  common  purpose  where  safety  is  of  paramount  importance. 

8,  Framework  for  Software  Reuse 

Successful  software  reuse  requires  a  holistic,  systematic,  multi-disciplinary 
approach  which  is  matched  to  the  specific  context  of  use.  I  intend  to  establish  a 
framework  within  which  software  reuse  can  be  enabled  and  supported  and  the  probability 
of  a  successful  outcome  increased  in  a  safety-critical  system  of  systems  context. 
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This  framework  requires  the  integration  of  a  number  of  faetors  to  be  sueeessful. 

Mueh  of  the  sueeess  of  any  reuse  program  ean  be  attributed  to  the  amount  of 
information  available  on  a  potential  reuse  eandidate,  the  ability  to  seareh  and  loeate  that 
information,  and  supportive  organizational  polieies  whieh  eneourage  reuse.  To  a  lesser 
degree,  sueeess  ean  also  be  attributed  to  institutionalized  memory  based  on  past 
experienees  employing  software  reuse  that  will  eontribute  to  future  organizational 
policies  on  software  reuse. 

This  framework  will  establish  the  organizational  policy  and  culture  requirements, 
the  information  required  on  a  reusable  software  component  and  its  possible  organization, 
metrics  that  are  of  interest,  requirements  from  a  regulator  or  certification  authority’s 
perspective,  and  the  hazard  analysis  that  must  occur  to  make  software  reuse  a  success  in 
safety-critical  system  of  systems. 

This  thesis  will  focus  on  compositional  reuse  rather  than  generative  reuse,  as 
described  by  Lim.27  Generative  reuse  software  is  a  tool  for  producing  software  artifacts 
that  may  be  compositionally  reused;  however,  the  framework  may  provide  value  in  that 
area  too. 

Chapter  II  will  provide  an  overview  of  standard  DO-178B,  Software 
Considerations  in  Airborne  Systems  and  Equipment  Certification,  which  will  provide  the 
context  for  discussion  of  an  Advisory  Circular  on  Reusable  Software  Components 
(AC20-148)  issued  by  the  Federal  Aviation  Administration  (FAA).  The  Advisory 
Circular  on  Reusable  Software  Components  provides  an  example  of  how  reuse  is 
encouraged  and  a  process  established  to  make  it  more  prevalent  and  ubiquitous  in  the 
U.S.  aviation  community. 

Chapter  III  introduces  the  framework  for  software  reuse  in  safety-critical  system 
of  systems,  the  metrics  relevant  to  safety,  reuse  metrics,  regulator  needs,  and  their 
influence  on  elements  of  the  framework.  Chapter  IV  provides  an  example  of  how  to 
apply  the  framework,  and  Chapter  V  draws  some  conclusions  and  discusses  future  work. 

27  W.C.  Lim.,  Managing  Software  Reuse,  A  Comprehensive  Guide  to  Strategieally  Reengineering  the 
Organization  for  Reusable  Components,  Upper  Saddle  River,  NJ.:  Prentiee  Hall  PTR,  1998,  p397. 
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II.  THE  FEDERAL  AVIATION  ADMINISTRATION  APPROACH 

TO  SOFTWARE  REUSE 


A,  DO-178B  SOFTWARE  CONSIDERATIONS  IN  AIRBORNE  SYSTEMS 

AND  EQUIPMENT  CERTIFICATION 

1,  Overview 

RTCA/DO-178B28  Software  Considerations  in  Airborne  Systems  and  Equipment 
Certifieation  is  a  contemporary  software  assurance  standard  that  is  highly  regarded  within 
the  aviation  community.  It  is  the  preferred  standard  for  software  assurance  for  safety 
related  airborne  software  in  the  Australian  Defence  Force  (ADF)  and  the  U.S.  Federal 
Aviation  Administration  (FAA)  and  is  used  by  many  others  developing  or  regulating 
airborne  software.  DO-178B  provides  guidelines  on  software  production  for  airborne 
systems  and  equipment.  The  standard  could  be  applied  across  application  domains  but 
some  aspects  are  avionics  specific. 

DO-178B  applies  to  the  assurance  and  certification  of  all  software  requirements 
and  not  just  those  that  are  safety  related.  In  DO-I78B,  two  main  entities  are  described, 
those  being  the  Certification  Authority  and  the  Applicant.  The  Certification  Authority  is 
the  organization  or  person  granting  approval  on  behalf  of  the  country  responsible  for 
aircraft  or  engine  certification29  and  is  the  organization  that  defines  certification 
requirements,  conducts  reviews  of  compliance  with  safety  requirements,  and  certifies 
compliance  with  the  requirements.  The  Applicant  is  the  person  or  organization  seeking 
approval  from  the  Certification  Authority  and  therefore  is  the  party  responsible  for 
providing  the  argument  and  evidence  for  certification.  The  FAA  uses  DO-178B  when 
certifying  airborne  software,  and  it  is  thus  the  standard  that  developers,  integrators,  and 
users  of  airborne  software  must  comply  with  to  achieve  certification  from  the  FAA.  DO- 
178B  is  also  the  preferred  standard  of  the  ADF  for  assurance  of  airborne  software. 

28  Radio  Technical  Commission  for  Aeronautics,  DO-178B  /  ED-12B,  Software  Considerations  in 
Airborne  Systems  and  Equipment  Certification,  Washington  D.C.,  1  December  1992. 

29  Ibid.,  p.  12. 


15 


B,  FAA  AC20-148  REUSABLE  SOFTWARE  COMPONENTS  (RSC) 


1.  Overview 

According  to  Wlad,  no  formal  guidance  or  standard  exists  that  maximizes  the 
utility  of  software  reuse  in  any  industry. 30  For  the  development  of  software  for  use  in 
safety-eritieal  system  of  systems,  a  the  Federal  Aviation  Administration  (FAA)  issued  a 
relatively  new  poliey  to  provide  some  guidanee  on  the  eertifieation  requirements  when  an 
already  eertified  software  eomponent  is  to  be  reused,  but  this  does  not  foeus  on  the  design 
for  reuse  or  those  inherent  attributes  that  the  software  eomponent  must  exhibit  to 
faeilitate  effeetive  reuse.  Wlad  asserts  that  this  new  poliey  will  eause  a  major  shift  in  how 
software  is  reused  in  safety  eritieal  systems.  The  new  poliey  is  a  Reusable  Software 
Components  Advisory  Cireular  (AC20-148)  published  in  2004.  This  eireular  details  the 
approaeh  and  doeumentation  neeessary  for  systematie  reuse  of  software  eomponents  that 
meet  the  guidelines  of  DO-178B.  AC20-148  now  allows  for  aoeeptanee  of  software 
independent  of  a  hardware  platform,  enabling  developers  to  take  eertifieation  eredit  on 
one  projeet  and  apply  it  to  future  projeets. 

The  FAA  asserts  that  this  approaeh  is  one  aeeeptable  means  of  eomplianee  but  not 
the  only  one  to  gain  aoeeptanee  or  eredit  for  the  reuse  of  a  software  eomponent.  As  this  is 
an  advisory  eireular,  it  is  not  mandatory  nor  does  it  oonstitute  a  regulation.  This  AC  only 
applies  when  all  stakeholders  agree  that  the  software  eomponent  is  reusable  beoause 
meeting  the  poliey  requirements  is  likely  to  require  additional  effort  and  resouroes.  The 
AC  may  apply  to  verifioation  and  development  tools,  although  the  FAA  plans  to  eover 
this  speoifieally  in  future  guidanee.  The  motivation  for  this  guidanee  eomes  from  the 
eeonomie  ineentives  of  reuse,  eneouraging  software  developers  to  develop  reusable 
software  eomponents  (RSCs)  that  ean  be  integrated  into  many  systems.  DO-178B  based 
verifieation  of  systems  is  known  to  be  an  expensive  endeavor.  Providing  a  meehanism  for 
taking  eredit  on  one  projeet  and  using  it  on  another  via  use  of  an  RSC  reduees  both 


30  J.  Wlad.,  Software  Reuse  in  Safety  eritieal  Airborne  Systems,  in  Proe  of  25th  Digital  Avionies 
Systems  Conferenee,  Oet  15,  2006,  p.  6C5-1. 
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certification  cost,  time,  and  risk.  The  guidance  in  the  AC  ensures  that  systems  using 
RSCs  meet  all  applicable  RTCA/DO-178B  objectives. 

The  FAA  may  grant  acceptance  of  an  RSC  provided  all  stakeholders  comply  with 
the  advisory  circular  and  that  no  installation,  safety,  operational,  functional,  or 
performance  concerns  are  identified.  Essentially  this  AC  increases  the  certification 
requirements  and  documentation  for  the  component  in  the  first  instance,  making  it  easier 
for  subsequent  uses  of  the  software  component.  The  AC  makes  a  good  point  in  that 
acceptance  of  the  RSC  for  one  project  does  not  guarantee  acceptance  on  a  later  project  as 
applicants  must  consider  installation,  safety,  operational,  functional,  and  performance 
issues  for  each  project.  This  is  important  because  safety  is  a  system  property.  Just 
because  there  are  no  safety  issues  in  one  environment  does  not  preclude  them  from 
existing  in  the  new  environment,  which  is  particularly  important  in  a  system  of  systems. 
In  other  words,  the  RSC  is  not  to  be  reused  blindly  and  should  be  assessed  for  each 
project  or  environment.  The  approach  identified  in  the  AC  requires  a  close  working 
relationship  between  the  FAA,  the  developer,  and  other  stakeholders  in  addition  to  the 
provision  of  evidence  to  support  the  argument  that  the  RSC  satisfies  all  DO-178B 
objectives  throughout  the  development  of  the  system.  Table  1  shows  the  failure 
conditions  of  the  safety  requirements  that  have  been  allocated  to  software  as  the  source 
and  the  number  of  objectives  that  require  evidence.  For  example,  a  software  failure 
condition  that  is  catastrophic  receives  a  level  of  A  and  requires  evidence  to  support  66 
objectives. 


Failure 

Condition 

Software 

Level 

Number  of 
Objectives 

Catastrophic 

Level  A 

66 

Hazardous  / 
Severe  -  Major 

Level  B 

65 

Major 

Level  C 

57 

Minor 

Level  D 

28 

Table  1.  178B  Software  Fevels 


17 


The  advisory  circular  recognizes  that  on  a  project  the  developer,  integrator,  and 
applicant  for  an  RSC  may  be  different,  and  even  when  an  applicant  plays  all  three  roles, 
there  needs  to  be  a  process  for  communicating  and  transferring  accepted  data  among  the 
relevant  stakeholders.  The  advisory  circular  addresses  that  communication  and  transfer  of 
data  and  identifies  what  information  each  party  to  the  RSC  must  produce.  The  advisory 
circular  recognizes  the  need  for  a  greater  level  of  DO-178B  compliance  and  evidence 
thereof  through  documentation  when  applying  for  acceptance  of  an  RSC.  The  advisory 
circular  is  also  more  specific  than  DO-178B  as  to  what  the  DO-178B  deliverables  should 
contain  to  comply  with  the  advisory  circular.  Table  2  lists  the  DO-178B  deliverables 
required  for  certification. 


Plan  for  Software  Aspects  of  Certification 

Software  Development  Plan 

Software  Verification  Plan 

Software  Configuration  Management  Plan 

Software  Quality  Assurance  Plan 

Software  Standards  (Reqs/Design/Code) 

Software  Requirements 

Design  description 

Source  code 

Review  results 

Test  procedures/Test  results 

Software  Life  Cycle  Environment  Index 

Software  Configuration  Index 

Problem  reports 

Software  Configuration  Management  records 

Software  Quality  Assurance  records 

Software  Accomplishment  Summary 

Table  2.  DO- 178B  Deliverables 
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The  advisory  circular  also  describes  the  data  requirements  that  the  developer  must 
provide  to  the  integrator  or  applicant.  As  an  example,  data  requirements  include  failure 
conditions,  safety  features,  protection  mechanisms,  architecture,  limitations,  software 
levels,  interface  specifications,  and  intended  use  of  the  RSC.  Furthermore,  open  problem 
reports  on  the  RSC  and  analysis  of  any  potential  functional,  operational,  performance, 
and  safety  effects  must  be  provided;  this  is  particularly  important  in  assessing  the 
appropriateness  for  a  particular  context  of  use  and  in  transferring  safety  information. 
Another  positive  approach  taken  in  the  advisory  circular  is  that  regardless  of  any  legal 
and  proprietary  issues  and  agreements  about  the  delivery  of  software  life  cycle  data  (or 
artifacts)  between  the  applicant  and  the  developer,  the  data  must  be  available  for  the 
certification  authority  or  authorized  designee’s  review  and  inspection.  This  places  the 
interest  of  public  safety  above  all  other  concerns.  This  means  that  complete  information 
is  disclosed  to  the  certification  authority  even  if  the  applicant  or  integrator  does  not  have 
access  to  it,  overcoming  the  potential  adverse  impact  proprietary  protection  may  place  on 
safety. 

The  FAA  also  requires  that  the  developer  submit  a  data  sheet  for  the  RSC  which 
must  concisely  summarize: 

•  RSC  functions 

•  Limitations 

•  Analysis  of  potential  interface  safety  concerns 

•  Assumptions 

•  Configuration 

•  Supporting  data 

•  Open  problem  reports 

•  Software  characteristics 

•  Other  relevant  information  that  supports  the  integrator’s  or  applicant’s  use 
of  the  RSC 
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This  data  sheet  also  assists  in  inereasing  the  understandability  of  the  software 
eomponent,  eharacterizing  what  information  is  deemed  important.  There  are  also 
provisions  and  requirements  placed  on  the  developer  for  identifying  and  maintaining  data 
to  support  changes  to  the  RSC. 

Military  aviation  regulators  could  take  advantage  of  the  approach  described  in  the 
advisory  circular  when  full  information  disclosure  may  not  be  achievable  or  required  with 
all  stakeholders  but  that  information  is  made  available  to  the  regulator.  Taking  the 
approach  identified  in  the  AC  may  reduce  some  of  the  verification  activities  required  on 
subsequent  projects  and  reduce  the  requirement  to  redo  DO-178B  certification  activities. 
The  advisory  circular  also  identifies  potential  software  reuse  issues  and  provides  a 
process  for  recertification  when  changes  are  made  to  an  RSC. 

Overall  the  advisory  circular  provides  thorough  and  systematic  guidance  for  the 
acceptance  and  credit  for  reuse  of  a  reusable  software  component.  The  advisory  circular 
specifies  the  process,  the  information  needs  of  all  parties,  some  potential  reuse  problems, 
and  how  to  gain  recertification  of  an  RSC  after  changes  to  it  are  made.  The  advisory 
circular  recommends  the  use  of  DO-178B  as  the  relevant  standard  for  initial  and  future 
compliance;  however,  this  is  not  mandatory  but  it  would  be  more  difficult  if  another 
standard  was  used.  It  recognizes  the  importance  of  a  design  for  reuse  approach  and  the 
allocation  of  appropriate  resources  to  gain  credit  for  the  early  work  when  reused.  Just  like 
safety  and  other  issues,  consideration  of  reuse  issues  as  early  as  possible  in  the  system 
development  is  much  more  efficient  in  assuring  effective  reuse  than  delaying 
consideration  until  after  many  of  the  design  and  development  decisions  have  been  made. 

A  deficiency  of  the  advisory  circular  is  that  it  does  not  specifically  refer  to  the  use 
of  hazard  analysis,  which  is  a  cornerstone  of  safety  engineering,  nor  what  the  information 
requirements  for  providing  evidence  to  support  a  safety  case  in  the  new  context  of  use.  A 
safety  case  sets  out  the  safety  justification  for  the  system  and  contains  a  record  of  all  the 
safety  activities  associated  with  a  system  throughout  its  life.^i  The  advisory  circular  does 


31  N.  Storey.,  Safety-Critical  Computer  Systems,  New  York,  NY.:  Addison- Wesley,  1996,  p364. 

20 


recommend  that  safety  must  be  considered  and  addressed,  which  may  be  the  authors’  way 
of  providing  the  evidence  in  support  of  the  safety  case  for  the  component;  however,  this 
was  not  explicit. 

As  this  advisory  circular  is  not  mandatory  and  represents  guidance  only,  but  refers 
to  DO-178B  as  the  certification  basis,  it  must  be  recognized  that  this  approach  will  be 
seen  as  the  preferred  and  most  common  way.  The  advisory  circular  does  not  preclude  the 
use  of  other  ways  of  achieving  RSC  certification;  however,  it  makes  compliance  with 
other  standards  more  arduous  by  specifically  referring  to  DO-178B,  thereby  perpetuating 
and  encouraging  its  use.  Thus  this  advisory  circular  becomes  a  de  facto  standard  for 
reusable  software  component  certification  within  U.S.  civil  aviation.  The  advisory 
circular  is  the  FAA’s  recognition  that  reusable  software  components  are  important  and  a 
process  to  achieve  certification  and  attain  credit  for  subsequent  uses  is  beneficial. 
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III.  FRAMEWORK  FOR  SOFTWARE  REUSE  IN  SAFETY- 
CRITICAL  SYSTEM  OF  SYSTEMS 

A,  OVERVIEW 

According  to  Lim,  software  reuse  is  most  effective  when  practiced 
systematieally .32  In  order  to  aehieve  a  systematie  approach  that  is  also  holistic  and 
multidisciplinary,  a  framework  for  software  reuse  in  safety-eritical  system  of  systems  is 
required  for  identifying  the  key  aspects,  factors,  and  influencers  on  software  reuse  and  for 
generating  diseussion  on  them.  It  is  therefore  proposed  that  the  suecessful  applieation  of 
software  reuse  in  a  systematic  approach  depends  on  the  following  four  factors  (or  pillars): 

1 .  Organizational  Factors  (Enabler  or  Foundation). 

2.  Reusable  software  eomponent  attributes  (Quality). 

3.  Reusable  software  component  specifieation  (Knowledge  Capture  and  Seareh 

Effectiveness). 

4.  Safety  Analysis  (Environmental  Match). 

This  chapter  will  explore  these  four  factors  of  software  reuse  in  detail. 

The  particular  context  of  safety-critieal  system  of  systems  plaees  greater 
emphasis,  in  partieular,  on  factors  2  and  4  of  the  framework.  What  differentiates  this 
framework  from  a  framework  for  reuse  in  general  is  the  level  of  detail  in  each  element 
and  that  a  safety  or  hazard  analysis  and  in  particular  a  system-of-systems  hazard  analysis 
is  essential. 

The  framework  depleted  in  figure  3  shows  how  the  faetors  (or  pillars)  contribute 
to  achieving  effective  software  reuse  in  safety-eritical  system  of  systems.  In  this  case,  the 
framework  refers  to  the  supporting  structure  for  software  reuse.  It  is  proeess  neutral  and 
represents  the  desired  elements  for  successful  software  reuse. 


32  W.C.  Lim.,  Managing  Software  Reuse,  A  Comprehensive  Guide  to  Strategieally  Reengineering  the 
Organization  for  Reusable  Components,  Upper  Saddle  River,  NJ.:  Prentiee  Hall  PTR,  1998,  p.  10. 
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Figure  3.  Framework  for  Software  Reuse  in  Safety-Critical  System  of  Systems 


This  framework  focuses  on  compositional  reuse,  the  construction  of  new  software 
products  by  assembling  existing  reusable  artifacts,  rather  than  generative  reuse.  The 
framework,  however,  may  provide  value  for  the  latter. 

The  needs  and  policies  of  the  regulator  will  have  an  impact  on  any  reuse  program 

and  will  largely  dictate  the  activities  required  and  documentation  necessary  to  obtain  the 

benefits  of  software  reuse.  Example  regulators  include  the  FAA  for  civilian  aviation  in 
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the  United  States,  the  Naval  Air  Systems  Command  for  U.S.  Navy  (USN)  and  U.S. 
Marine  Corps  (USMC)  aviation,  and  the  Australian  Defence  Force  (ADF)  for  military 
aviation  in  Australia.  The  specific  regulator  for  the  safety-critical  system  of  systems  will 
have  influence  on  the  framework  as  evident  in  the  discussion  of  the  FAA’s  influence  on 
software  reuse  through  its  guidance  (Advisory  Circular  20-148). 

B,  ORGANIZATIONAL  FACTORS 

Organizational  factors  represent  the  enabling  and  supporting  functions  within  an 
organization  that  must  exist  to  achieve  successful  software  reuse  in  any  context.  These 
non-technical,  management  factors  have  significant  influence  on  any  software  reuse 
activity  and  if  not  aligned  appropriately,  can  dramatically  affect  the  success  of  any 
proposed  software  reuse.  Effective  software  reuse  requires  a  strong  commitment  from 
senior  management,  a  documented  process  that  supports  the  organization’s  mission,  a 
software  reuse  policy,  and  a  delegated  software  reuse  team.  The  significant  factors 
affecting  software  reuse  from  an  organizational  perspective  fall  into  the  following 
categories:  culture;  people;  structure;  reuse  domain;  reuse  potential;  reuse  capability; 
policies,  processes  and  practices;  and  reuse  metrics. 

1.  Culture 

Organizational  culture  is  defined  as  "consciously  held  notions  shared  by  members 
that  most  directly  influence  their  attitudes  and  behaviors. ”33  These  notions  may  include 
behavioral  norms,  values,  beliefs,  rituals,  symbols,  and  behaviors  that  employees  believe 
are  expected  of  them  to  fit  in  and  survive  in  an  organization.  Organizational  culture  can 
also  be  thought  of  as  the  leadership  and  management  style,  employee  involvement  and 
participation,  and  the  customs  and  norms  of  an  organization.  These  have  a  significant 
affect  on  the  performance  of  an  organization,  which  subsequently  affects  software  reuse 
efforts.  If  those  closely  held  notions  within  an  organization  are  not  conducive  to  software 
reuse,  then  it  will  be  difficult  for  the  organization  to  effectively  reuse  software.  If  the 


33  R.H.  Kilmann.,  M.J.  Saxton.,  R.  Serpa.,  Gaining  Control  of  the  Corporate  Culture,  Jossey  Bass 
Business  and  management  Series,  San  Francisco,  CA.:  1985. 
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leadership  and  management  style  promotes  reuse,  this  can  aid  in  the  successful 
implementation  of  a  reuse  program.  A  supportive  organizational  culture  cannot  guarantee 
the  success  of  software  reuse..  The  lack  of  a  supportive  organizational  culture,  however, 
will  almost  certainly  guarantee  failure.  The  leadership  and  management  of  an 
organization  have  a  significant  influence  in  this  regard,  and  they  must  both  buy  into 
software  reuse  and  promote  its  benefits  throughout  the  organization. 

It  is  not  easy  to  change  an  organizational  culture,  because  this  requires  changing 
the  ingrained  ways  of  that  which  defines  the  organization,  but  change  is  necessary  if 
software  reuse  is  to  be  successful  and  implemented  where  required.  Members  of  the 
organization  with  a  stake  in  software  development  must  buy  in  to  the  concept  of  software 
reuse  and  understand  its  purpose  for  it  to  be  a  success  across  the  organization.  For 
software  reuse  to  be  implemented  successfully,  it  is  essential  that  there  be  a  culture  of 
cooperation  and  collaboration  between  stakeholders  of  the  system  of  systems  to  ensure  all 
relevant  issues  are  considered  in  a  timely  and  effective  manner.  In  the  context  of  safety- 
critical  system  of  systems  what  is  desired  is  a  safety  culture  that  permeates  all 
organizations  that  contribute  to  the  system  of  systems.  This  reflects  the  ideal  and  may  not 
be  achievable  in  reality.  A  safety  and  reuse  champion  is  required  who  will  educate, 
influence,  and  align  the  other  stakeholders  to  achieve  the  necessary  organizational 
culture. 


2,  People 

People  are  a  key  component  in  the  implementation  of  software  reuse  in  an 
organization.  They  must  be  motivated  to  reuse  with  the  requisite  support  to  enable  them 
to  do  so.  People  must  understand  the  purpose  for  reusing  software  and  the  way  it  is  to 
occur.  Incentives  to  encourage  reuse  must  be  used  to  affect  attitudinal  changes  towards  its 
practice.  Without  any  one  of  these,  the  best  efforts  may  come  undone. 
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Furthermore,  the  right  people  need  to  be  placed  in  the  right  positions  to  have  a 
positive  impact  on  the  software  reuse  efforts  of  an  organization.  Possible  positions  could 

include:  34 

a.  Reuse  Champion, 

b.  Domain  Analyst, 

c.  Domain  Expert, 

d.  Domain  Workproduct  Manager, 

e.  Reuse  Engineer, 

f  Reuse  Analyst, 

g.  Reuse  Economist/Metrician, 

h.  Eibrarian,  and 

i.  Reuse  Manager. 

If  software  reuse  is  to  be  successful,  all  the  preceding  roles  should  be  played  in 
large  and  in  small  organizations;  however,  you  could  have  different  numbers  of  people 
responsible  for  each  position.  Eor  example,  you  may  have  one  person  for  each  position; 
one  person  fulfilling  more  than  one  position;  or  the  responsibilities  of  each  position  being 
fulfilled  by  a  team  of  people.  It  is  essential  for  an  effective  reuse  program  to  select  the 
right  staff  for  each  position  and  educate,  train,  and  motivate  them. 

A  change  in  attitude  and  culture  is  important  for  long-term  reuse  success.  The 
means  for  achieving  a  change  in  attitude  and  culture  include  education  and  training  along 
with  communication  of  the  purpose  of  the  reuse  initiative.  It  is  often  the  lack  of 
communicating  the  goals  of  the  reuse  initiative  that  lets  down  the  initiative  and  prevents 
it  from  being  successful.  Good  management  of  the  people  filling  the  position  cannot  be 


34  W.C.  Lim.,  Managing  Software  Reuse,  A  Comprehensive  Guide  to  Strategieally  Reengineering  the 
Organization  for  Reusable  Components,  Upper  Saddle  River,  NJ.:  Prentiee  Hall  PTR,  1998,  pp225-227. 
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overstated  in  order  to  aehieve  sueeess  in  software  reuse.  All  the  people  responsible  for 
software  development  and  maintenanee  have  a  role  in  sueeessfully  implementing 
software  reuse. 

3.  Structure 

The  typieal  organizational  struetures,  sueh  as  funetional,  projeet,  matrix,  and 
eombinations  thereof,  may  be  used  for  reuse.  Eaeh  strueture  has  its  advantages  and 
disadvantages;  these  are  dependent  on  the  eontext  for  reuse.  The  best  strueture  to  apply 
will  depend  on  the  eharaeteristies  of  the  organization,  the  reuse  strategy,  and  the 
environment  that  it  will  oeeur  in.  It  is  important  to  ehoose  the  right  organizational 
strueture  that  will  deliver  the  reuse  strategy  given  the  organizational  eharaeteristies  and 
operating  environment.  In  safety-eritieal  system  of  systems  in  whieh  eomponent  quality 
and  adherenee  to  safety  requirements  is  eritieal  for  software  reuse,  the  best  organizational 
strueture  may  be  a  funetional  organization,  where  there  is  eonsisteney  in  personnel, 
greater  retention  of  eorporate  knowledge  (or  institutional  memory),  and  the  ability  to 
eentralize  reuse  efforts  and  effieiently  manage  them.  Furthermore,  under  a  funetional 
organization  it  is  more  likely  that  eommon  standards  and  methods  will  be  reinforeed  and 
applied  to  the  partieular  reusable  artifaets  in  eaeh  funetional  area.  However,  just  as  there 
is  the  potential  for  greater  quality  and  eonsisteney  among  partieular  reusable  artifaets,  the 
funetional  strueture  may  not  be  as  responsive  to  eustomer  needs  as  the  other 
organizational  struetures  and  suffer  from  eoordination  problems  between  the  funetional 
departments  of  the  reusable  artifaets  thus  ereating  issues  when  eomponents  are  to  be 
reused.  An  organization  does  not  neeessarily  strueture  itself  based  on  what  is  best  for 
reuse,  so  that  strueture  may  not  be  suitable  in  all  eases.  In  strueturing  an  organization  for 
reuse,  it  is  also  important  to  ensure  that  there  are  reuse  departments  responsible  for  the 
management  of  the  reusable  artifaets.  These  departments  will  maintain  software 
repositories.  An  eeosystem  supporting  reused  software  in  an  organization  is  important. 35 


35  R.  Anthony.,  Software  Firms  Reap  Benefits  of  Code  Reuse.  The  Wall  Street  Journal,  December  3, 
2007.  www.livemint.com, http://www.livemint.eom/2007/12/0323341 1/Software-firms-reap-benefits- 
o.html 
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4. 


Reuse  Domain 


The  market  segment  the  organization  is  serving,  the  types  of  produets  the 
organization  produces,  or  the  public  sector  the  organization  is  in  often  define  the  reuse 
domain.  This  influences  what  form  software  reuse  should  take  and  how  it  is  performed. 
Competition  and  regulation  within  the  domain  of  reuse  will  shape  software  reuse,  define 
what  is  involved,  motivate  its  use,  and  impact  on  its  ultimate  success.  A  stable  operating 
domain  for  the  organization  will  assist  in  making  reuse  decisions  and  in  exploiting  reuse 
to  its  full  potential.  A  domain  characterized  by  frequent  disruptive  technologies  may 
provide  little  impetus  for  establishing  or  investing  in  a  software  reuse  program. 

5.  Reuse  Potential 

Lim  refers  to  a  reuse  potential  and  aptitude  modeP^  to  help  firms  identify  their 
potential  for  reuse  success.  This  model  is  based  on  the  assumption  that  the  organization 
must  possess  the  requisite  potential  for  reuse  as  well  as  the  ability  to  successfully  exploit 
that  potential.  Reuse  potential  represents  the  latent  redundancies  and  opportunities  within 
and  across  domains  which,  when  combined  with  proper  organizational  ability,  can 
become  actual  reuse.37 

Latent  competencies  or  opportunities  must  exist  for  the  organization  in  order  to 
have  reuse  potential.  A  number  of  organizational  characteristics  influence  reuse  potential 
and  provide  the  supporting  basis  for  future  reuse. 

6,  Reuse  Capability 

In  order  to  recognize  reuse  potential,  an  organization  must  possess  the  capability 
to  exploit  the  potential.  Reuse  aptitude  (capability)  refers  to  the  requisite  ability  or 
capacity  to  exploit  the  reuse  potential. 38  This  aptitude,  capacity,  or  capability  refers  to  the 
ability  to  turn  potential  into  reality  and  consists  of  the  organizational  characteristics, 

36  W.C.  Lim.,  Managing  Software  Reuse,  A  Comprehensive  Guide  to  Strategically  Reengineering  the 
Organization  for  Reusable  Components,  Upper  Saddle  River,  NJ.:  Prentice  Hall  PTR,  1998,  pp  75. 

37  Ibid.,  p.  75. 

38  Ibid.,  p.  78. 
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competencies,  resources,  or  access  to  resources  in  order  to  implement  software  reuse. 
Software  reuse  involves  an  investment  and  effort  upfront,  which  can  be  up  to  forty 
percent  more  than  software  written  without  reuse  in  mind  (not  to  mention  the  costs  of 
establishing  a  reuse  program  initially). 39  Moreover,  an  organization  requires  those 
additional  resources  at  the  right  time  in  order  to  implement  reuse.  If  an  organization  does 
not  have  the  resources  or  access  to  resources  when  required,  it  will  not  be  able  to 
successfully  implement  a  reuse  program  and  fulfill  its  reuse  potential.  The  specific  reuse 
capabilities  required  are  referred  to  throughout  this  chapter. 

7.  Policies,  Processes  and  Practices 

The  members  of  an  organization  must  understand  the  purpose  of  software  reuse 
and  develop  policies,  processes,  and  practices  that  are  supportive  of  reuse.  The  policies, 
processes,  and  practices  must  be  supportive  of  software  reuse  for  it  to  be  a  success.  These 
policies  and  processes  must  be  clearly  defined  and  consistent  with  organizational  culture 
and  provide  clear  guidance  on  how  it  will  be  implemented  and  who  is  responsible,  in 
much  the  same  way  as  AC20-148  does.  The  policies,  processes,  and  practices  must 
incentivize  software  reuse,  rewarding  the  practice  and  cementing  it  into  the 
organizational  culture.  It  is  the  policies,  processes,  and  practices  that  will  form  an 
organization’s  culture  over  time,  and  to  succeed  reuse  must  become  part  of  that  culture.  A 
reusability  culture  will  be  created  over  time  through  organizational  policies,  processes, 
and  practices.  Meyer  defines  reusability  culture  as  one  in  which  all  software  is  developed 
under  the  assumption  that  it  will  be  reused.'^o  He  also  says  that  the  reusability  of  any 
software  should  not  be  trusted  until  it  has  been  reused.  This  essentially  supports  the 
treatment  of  reusability  concerns  throughout  development  and  that  just  because  software 
has  been  designed  that  way  does  not  mean  that  it  is  reusable  in  another  context  without 


39  R.  Anthony.,  Software  Firms  Reap  Benefits  Of  Code  Reuse.  The  Wall  Street  Journal,  December  3, 
2007.  www.hvemint.com, http://www.livemint.eom/2007/12/0323341 1/Software-firms-reap-benefits- 
o.html 

40  M.  Meyer.,  Object-Oriented  Software  Construction,  Second  Edition,  Upper  Saddle  River,  NJ.: 
Prentice  Hall  PTR,  1997,  p.  929. 
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sufficient  evidence.  This  philosophy  was  also  evident  in  the  FAA  AC20-148  Reusable 
Software  Components  guidance  and  by  this  framework. 

Reuse  involves  taking  advantage  of  previous  successes  and  in  order  to  continue, 
policies  must  support  it  and  not  overly  reward  the  use  of  newly  created  software.  If 
people  are  paid  more  to  create  their  own  software  rather  than  reuse  existing  software  and 
past  successes,  the  outcome  will  be  predictable.  This  suggests  that  an  organization  should 
have  policies  and  processes  that  enable  a  learning  organization  and  have  supportive 
metrics  and  compensation  policies  for  reuse.  The  organization  with  a  reuse  strategy  and 
goal  must  utilize  metrics  that  assess  the  progress  towards  that  goal.  These  metrics,  based 
on  data  and  information  gained  from  the  reuse  of  software  and  on  the  impact  of  software 
reuse,  should  inform  policy  decisions,  therefore  providing  feedback  and  an  improvement 
mechanism  for  the  organization.  Aligning  compensation  to  reuse  or  creating  a  learning 
organization,  one  that  learns  from  its  successes,  means  that  delivering  repeatable  results 
are  viewed  more  highly  than  one  off  results.  Repeatable  results  built  on  the  foundations 
laid  by  others  should  be  viewed  as  more  valuable  than  any  single  results  alone. 

These  reuse  processes  and  practices  must  be  integrated  into  the  existing  software 
development  process.  For  software  reuse  to  permeate  the  system  of  systems,  partnerships 
between  stakeholders  that  will  be  promoted  in  policy  and  fostered  by  people  are  essential. 
These  partnerships  will  be  both  intra-  and  inter-organization  for  software  reuse  to  be  a 
success.  An  example  policy  that  will  create  and  foster  partnerships  is  a  communication 
plan  between  the  member  organizations  of  the  system  of  systems  which  will  define  the 
different  types  of  communication,  what  they  will  be  used  to  convey,  and  who  is 
responsible  for  each. 

Other  interesting  business  practices  where  reuse  is  encouraged  include  software 
development  companies  offering  discounts  for  the  retention  of  intellectual  property  (IP) 
rights  for  the  software  developed  for  clients  so  that  they  can  reuse  it  on  their  future 
projects  without  requiring  completely  new  developments  or  violating  IP  rights.  This 
encourages  the  company  to  reuse  and  to  capture  some  of  the  original  development  cost  of 
the  software  on  future  projects.  It  encourages  software  developers  to  design  for  reuse  and 

to  consider  other  potential  users  of  the  same  software. 
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On  the  other  hand,  reuse  is  enabled  through  transpareney  and  the  delivery  of 
required  IP  rights  to  the  eustomer.  An  example  of  this  is  the  U.S.  Navy’s  open 
arehiteeture  (OA)  strategy,^!  a  multi-faeeted  strategy  providing  a  framework  for 
developing  joint  interoperable  systems  that  adapt  and  exploit  open-system  design 
prineiples  and  arehiteetures.  This  framework  ineludes  a  set  of  prineiples,  proeesses,  and 
best  praetiees  that,  among  other  things,  aehieves  eomponent  software  reuse.  By  requiring 
open  arehiteetures  and  henee  transpareney  of  eomponents,  they  are  more  readily  reused 
by  the  Department  of  Defense  (DoD)  and  those  who  the  DoD  wishes  to  eontraet  with. 
However,  in  order  to  aehieve  this,  the  USN  will  likely  have  to  pay  a  premium  for  that 
transpareney  and  quality  of  the  software  upfront  and  henee  eommit  to  reuse  to  avoid 
exeessive  eosts  overall  on  its  programs.  The  Navy  requires  that  on  eaeh  projeet  it  obtains 
and  retains  flexible  IP  rights  and  the  IP  rights  it  agrees  to  be  based  on  the  rights  being 
offered,  the  rights  the  Government  wants  or  needs,  and  the  potential  reuse  for  that 
software.  The  IP  rights  obtained  and  retained  should  be  dependent  on  where  the  reuse  is 
to  oeeur  and  who  is  likely  to  reuse  the  software.  Open  IP  rights  faeilitates  reuse  as 
interfaees  ean  easily  be  determined;  however,  IP  rights  ean  be  limited  but  promote  reuse 
as  long  as  interfaees  are  known  and  the  organization  responsible  for  the  eomponent 
development  is  involved  in  the  reuse  effort. 

The  level  of  IP  rights  obtained  and  poliey  adopted  in  the  aequisition  of  software 
will  depend  on  the  type  of  aequisition.  In  between  these  two  approaehes  may  lie  a  way  to 
aehieve  a  suffieiently  open  arehiteeture  while  minimizing  eosts  and  allowing  the  software 
developer  to  keep  the  IP  for  subsequent  reuse  both  within  DoD  and  externally.  It  may  be 
the  ease  that  subsequent  reuse  by  a  DoD  software  supplier  is  subjeet  to  government 
approval.  Another  approaeh  maybe  that  the  government  eould  initially  own  the  IP  but  if  a 
reuse  opportunity  is  available,  the  eompany  applies  to  the  government  for  approval  with 
some  potential  royalties  and  diseounts  on  maintenanee  (evolution)  as  a  result  being 
passed  baek  to  the  government.  What  is  required  is  a  way  to  effeetively  eontrol  the 
software,  eneourage  reuse,  and  minimize  overall  eost  so  that  aeeess  is  available  to  the 
right  information  when  it  is  required. 

41  Naval  Open  Architecture,  October  2007,  https://acc.dau.mil/oa. 
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The  FAA’s  Reusable  Software  Components  advisory  eireular  AC20-148  provides 
a  proeess  for  the  regulator  to  review  all  relevant  information  for  safety,  regardless  of 
whether  the  eustomer  has  all  the  information.42  Maybe  the  DoD  airworthiness  regulators 
eould  implement  a  similar  approaeh  where  they  have  aeeess  to  all  IP  but  the  respeetive 
user  does  not  neeessarily,  thus  removing  the  requirement  for  the  user  to  pay  for  it  in  order 
to  ensure  that  it  ean  be  reused  safely.  This  may,  however,  ereate  a  eonfliet  of  interest  as 
the  airworthiness  regulator  is  often  not  independent  from  the  end  user  of  the  software 
eomponent. 

Software  for  safety-eritieal  system  of  systems  should  be  developed  with  an 
assumption  that  it  will  be  reused;  however,  it  will  not  be  blindly  reused  without 
eonsidering  its  new  eontext  and  performing  a  suffieient  safety  analysis.  Polieies  and 
proeesses  must  be  established  that  eneourage  and  support  reuse  so  that  it  is  performed 
safely.  Certain  policies  and  approaches  may  be  taken  depending  on  who  is  reusing  the 
software  and  for  what  purpose. 

A  DoD  policy  for  software  reuse  in  safety-critical  system  of  systems  is  required 
similar  to  the  FAA  AC20-148  that  encourages  reuse  in  the  right  circumstances  and 
provides  guidance  on  how  it  is  to  be  performed,  leveraging  previous  successful  software 
in  new  systems  development.  The  elements  of  that  policy  should  come  from  this 
framework  providing  guidance  on  how  software  reuse  will  occur  and  how  credit  can  be 
gained  to  make  future  software  and  system  development  more  effective  and  efficient. 

8,  Reuse  Metrics 

Frakes  and  Terry  established  many  useful  reuse  metrics  in  1996,^^3  and  only  minor 
refinements  have  been  made  since  then.  The  categorization  of  reuse  metrics  and  models 
included  cost-benefit  analysis,  maturity  assessment,  amount  of  reuse,  failure  mode 


42  Advisory  Circular  AC  20-148,  Reusable  Software  Components,  US  Department  of  Transportation, 
Federal  Aviation  Administration,  December  7,  2004. 

43  W.  Frakes.,  C.  Terry.,  Software  Reuse:  Metrics  and  Models.  ACM  Computing  Surveys,  28(2),  June 
1996,  p.  415-435. 
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analysis,  reuse  assessment  and  reuse  library  metries.  Lim^^  developed  a  framework  for 
reuse  metries  based  on  the  same  Goal-Question-Metrie  paradigm  deseribed  earlier  to 
divide  reuse  metries  into  the  following  six  types:  Eeonomie  Metries,  Primary  Metrics, 
Library  Metrics,  Process  Metrics,  Product  Metrics,  and  Asset  Metrics.  The  exact  choice 
of  metrics  from  those  listed  above  will  be  based  on  the  organization’s  particular  situation 
and  the  questions  it  requires  answers  to,  and  their  priorities.  Ideally  for  reuse  to  be 
successful,  it  must  be  economical  and  lend  itself  to  cost-benefit  analysis  and  all  other 
metrics  will  be  subordinate. 

9,  Conclusion 

Organizational  factors  affect  the  success  of  any  reuse  effort.  Without 
organizational  factors  that  support  reuse  and  their  integration  into  the  software 
development  process,  the  result  of  any  reuse  initiative  is  likely  to  fail.  For  reuse  to  be 
successful,  and  in  particular  in  safety-critical  system  of  systems,  these  organizational 
factors  need  to  be  aligned  such  that  they  support  systematic  and  careful  reuse.  Focusing 
on  the  technical  aspects  of  reuse  and  failing  to  address  the  non-technical  or  organizational 
aspects  will  condemn  any  large  scale  systematic  reuse  effort  to  failure.  Policies  should 
cover  the  conduct  of  software  reuse  and  maximize  the  utility  of  software  reuse  in  a 
systematic  way. 

C.  REUSABLE  SOFTWARE  COMPONENT  ATTRIBUTES 

1,  Overview 

In  consideration  of  those  attributes  the  reusable  software  should  possess,  the 
software  component  is  used,  as  it  represents  a  common  focus  of  reuse  and  a  sufficiently 
sized  entity  to  leverage  the  benefits  of  reuse. 


44  W.C.  Lim.,  Managing  Software  Reuse,  A  Comprehensive  Guide  to  Strategieally  Reengineering  the 
Organization  for  Reusable  Components,  Upper  Saddle  River,  NJ.:  Prentiee  Hall  PTR,  1998,  p.  301. 
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2. 


Definition  of  Software  Component 


A  software  component  is  a  collection  of  software  comprising  a  module  with  a 
well  defined  purpose  that  may  be  used  with  no  or  minimal  alteration.  A  component  is 
thus  a  bounded  element  in  a  design  and  can  be  a  single  unit  within  that  design.  A 
component  includes  both  tangible  (code,  design,  test  plans,  and  documentation)  and 
intangible  (e.g.  knowledge  and  methodologies)  elements.  Ideally,  a  software  component 
represents  a  reusable  piece  of  software  that  can  be  easily  integrated  with  other 
components  with  relatively  little  effort.  The  key  is  to  achieve  that  ideal  level. 

3.  Component  Attributes 

The  software  component  attributes  described  in  this  section  represent  the  ideals  or 
goals  as  it  may  not  be  possible  to  achieve  all  in  the  one  component.  The  following 
component  attributes  may  not  be  achievable  to  the  desired  level  and  the  exact  levels  will 
depend  on  the  results  of  trade  studies.  It  is  important  that  these  attributes  be  identified 
early  so  that  they  can  be  included  in  the  trade  studies  and  given  due  consideration. 
Consideration  of  those  desired  attributes  and  incorporation  of  them  into  the  development 
process  represents  a  design-for-reuse  approach.  As  mentioned  earlier  there  are  no 
standards  for  development  of  safety-critical  software  that  maximizes  the  utility  of 
software  reuse.^^  This  is  also  true  in  the  safety-critical  system  of  systems  context.  There 
is,  however,  some  guidance  on  the  certification  requirements  when  an  already  certified 
software  component  is  to  be  reused,^^  but  this  does  not  focus  on  the  design  for  reuse  or 
those  inherent  attributes  that  the  software  component  must  exhibit  in  order  to  support 
effective  reuse.  Thus,  the  focus  here  is  on  the  attributes  of  reusable  software  components 
for  use  in  safety-critical  system  of  systems.  That  is,  what  attributes  should  be  present  to 
make  component  reuse  easier  or  increase  reusability  of  software  in  safety-critical  system 


45  J.  Wlad.,  Software  Reuse  in  Safety  eritieal  Airborne  Systems,  in  Proe  of  25th  Digital  Avionies 
Systems  Conferenee,  Oet  15,  2006,  p.  6C5-1. 

46  Advisory  Cireular  AC  20-148,  Reusable  Software  Components,  US  Department  of  Transportation, 
Federal  Aviation  Administration,  Deeember  7,  2004. 
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of  systems.  It  is  important  that  components  be  designed  for  reuse,  in  that  they  exhibit 
these  attributes  as  they  will  become  members  of  the  repository  of  reusable  software 
components. 

Reusable  software  components  for  use  in  safety-critical  system  of  systems  should 
have  the  following  attributes: 

•  They  should  be  transparent  to  the  user  or  reuser,  exhibiting  an  open 
architecture  by  default,  including  the  essential  documentation  requirements  of  that 
component  (see  §3D  for  details  on  how  that  transparency  should  be  defined). 

•  The  component  should  do  one  thing  and  do  it  well  and  have  minimal 
interactions  with  other  components.  That  is,  the  component  should  be  highly  cohesive 
with  low  coupling.  Modular  design  should  be  adopted  where  functionality  is  partitioned 
into  discrete,  cohesive,  and  self-contained  elements  with  well  defined  interfaces.  This 
may  be  difficult  to  achieve  in  large  component  compositional  reuse;  however,  this  is  a 
goal  and  modularity  in  design  should  be  adhered  to  within  the  design  of  components. 

•  The  software  component  shall  consist  of  well  formed  modules,  be 
protected,  include  the  localization  of  data,  and  comply  with  the  criteria  and  principles  for 
modularity.  Meyer’s  criteria  for  modularity — decomposability,  composability, 
understandability,  continuity  and  protection — and  his  five  principles — direct  mapping 
(Linguistic  Modular  Units),  few  interfaces,  small  interfaces  (weak  coupling  and  limited 
information  exchange),  explicit  interfaces,  and  information  hiding  (providing  uniform 
access) — should  be  followed  in  the  design  of  reusable  software  components.47 

Decomposability  is  satisfied  if  it  is  possible  to  decompose  the  software  into  a 
smaller  number  of  less  complex  problems.  This  is  synonymous  with  the  “divide-and- 
conquer”  approach  to  problem  solving  and  the  fact  that  it  is  often  easier  to  construct  a 
complex  solution  from  the  composition  of  a  number  of  less  complex  solutions.  The  less 
complex  problems  should  be  connected  via  a  simple  structure  with  independence  to 
facilitate  further  work  proceeding  separately  on  each  one.  If  a  component  is 

47  M.  Meyer.,  Objeet-Oriented  Software  Construetion,  Seeond  Edition,  Upper  Saddle  River,  NJ.: 
Prentiee  Hall  PTR,  1997,  §  3. 1,3.2. 
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decomposable  it  will  be  easier  to  evolve  because  changes  can  be  focused  on  the 
respective  module.  Compos  ability  means  that  it  is  possible  to  remove  the  software 
element  from  the  environment  of  its  original  design  and  use  it  in  another  environment. 
Under standability  means  that  the  software  must  contain  sufficient  information  so  that  it 
can  be  understood.  This  is  also  relevant  for  the  evolution  process,  as  in  order  to  adapt  and 
modify  the  software  component  it  is  essential  that  it  be  understandable.  This  is  the  key  to 
component  specification,  which  will  be  discussed  in  the  next  section.  Continuity  means 
that  a  requirements  or  specification  change  will  only  result  in  change  of  just  one  module 
or  a  small  number  of  modules.  Protection  means  that  potential  abnormal  condition  will 
be  contained  within  a  module  or,  at  worst,  will  only  propagate  to  a  few  neighboring 
modules. 

Direct  Mapping  (Linguistic  Modular  Units)  means  that  there  should  be  structural 
correspondence  (direct  mapping)  between  the  solution  domain  and  the  problem  domain, 
as  described  by  the  model.  In  other  words,  a  module  should  ideally  perform  a  function  or 
implement  a  feature  from  the  problem  domain  description.  The  reusable  software 
component  should  have  as  few  interfaces  and  inter-communication  as  possible.  The  more 
relations  and  interfaces  between  modules,  the  more  likely  it  is  for  the  effect  of  a  change 
or  error  to  propagate  to  other  modules.  Those  interfaces  that  do  exist  should  be  small  and 
communicate  as  little  information  as  possible  (this  is  analogous  to  communication  with 
limited  bandwidth).  Those  interfaces  that  exist  must  be  explicit  and  obvious  from  the 
information  contained  in  each  module.  This  interface  information  should  be  made  explicit 
in  the  component  specification.  Information  hiding  or  uniform  access  principle  means 
that  the  implementation  details  of  the  services  offered  by  a  module  should  not  be  revealed 
but  access  to  those  services  made  available  through  a  uniform  notation. 

•  A  reusable  software  component  should  follow  the  “open-closed”  principle 
in  that  it  will  be  usable  as  it  stands  (closed)  while  still  being  adaptable  (open). 

•  The  software  components  should  be  generic  to  allow  for  type  variation 
and  thus  creating  a  wider  range  of  reuse.  It  should  be  independent  of  implementation. 
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•  The  software  eomponent  should  inelude  routine  grouping  in  order  to  be 
seif  suffieient  and  eover  all  possible  actions  required  for  a  particular  purpose  (i.e.,  include 
the  complete  set  of  routines  required  to  achieve  its  intended  purpose). 

•  The  software  component  should  cover  a  wide  variety  of  implementations 
through  a  module  family  where  it  is  not  possible  for  a  single  module  to  satisfy  all 
requirements,  thus  requiring  a  module  /  component  family. 

•  The  software  component  should  be  independent  of  representation;  that  is, 
the  module  should  be  able  to  carry  out  an  operation  without  knowing  implementation 
details  and  variants. 

•  The  software  component  should  factor  out  common  behaviors.  Instead  of 
having  a  component  for  every  type  of  implementation  such  as  in  a  family  of  components, 
common  behaviors  can  be  factored  out  and  modularized  into  a  component  reducing  the 
number  of  components  or  modules  in  a  family.  This  makes  the  reuse  decision  easier  than 
having  a  different  component  for  each  type  of  implementation.  This  is  a  principle  of 
modular  design  and  is  extended  further  by  Aspect-oriented  Programming  (AOP)  with  its 
focus  on  separation  of  concerns. 

•  The  component  shall  be  robust  in  its  environment.  That  is,  it  should  react 
appropriately  to  a  wide  range  of  abnormal  conditions  when  operating  in  the  context  of  a 
system  of  systems.  These  reactions  should  be  transparent  as  described  above.  Moreover, 
it  should  be  complete,  as  opposed  to  efficient,  and  able  to  handle  the  conditions  expected 
in  the  operating  environment  (safety-critical  system  of  systems)  with  consideration  given 
to  unexpected  but  possible  events.  In  an  environment  that  is  not  safety-critical,  it  may  be 
enough  for  the  component  to  perform  the  desired  function,  and  not  be  highly  dependable. 
However,  in  safety-critical  systems  it  is  essential  that  the  component  is  dependable,  or  in 
other  words,  from  a  safety  perspective,  failures  will  not  produce  hazardous  conditions.  In 
safety-critical  system  of  systems  the  component  must  be  complete  and  be  adequately 
dependable  (i.e.,  comply  with  the  dependability  requirements  of  the  software  system, 
derived  from  the  system  dependability  requirements).  Dependability  is  defined  as: 
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The  trustworthiness  of  a  computing  system  which  allows  reliance  to  be 

justifiably  placed  on  the  service  it  delivers 

Dependability  consists  of  the  attributes  of  reliability,  availability,  safety,  and 
security.  These  complete  components  should  include  error  handling,  be  fault  tolerant,  and 
satisfy  the  safety  attributes  of  the  dependability  requirements  of  the  software  system. 
Measuring  the  degree  to  which  a  software  component  is  complete  for  its  intended 
operating  environment  is  a  difficult  endeavor,  especially  given  the  size  of  the  input  and 
hazard  space.  To  be  complete  with  respect  to  requirements  is  different  then  being 
complete  with  respect  to  the  environment.  Only  when  the  set  of  software  component 
requirements  is  the  same  as  the  requirements  for  the  context  of  intended  use  can 
completeness  be  truly  measured,  and  it  is  very  difficult  to  determine  whether  these  sets 
are  the  same.  The  application  of  an  effective  requirements  elicitation  technique  that 
captures  context  of  use  requirements  including  safety  requirements  can  assist  in  ensuring 
that  these  sets  are  as  identical  as  possible.  Metrics  can  provide  an  indication  of 
completeness,  assuming  that  the  requirements  set,  including  safety  requirements,  is 
complete  for  the  intended  environment.  These  metrics  will  be  described  and  discussed  in 
§3F. 

•  The  software  component  should  be  free  of  default  behavior  that  the 
software  engineer  has  not  specifically  described  for  that  component. 

•  The  component  should  be  sufficiently  evaluated  and  tested  to  verify  the 
implementation  of  the  safety  attributes  and  requirements.  Producer  testing  has  been 
identified  as  one  of  the  critical  success  factors  for  reuse. Testing  is  essential  in 
producing  high  quality  software  and  for  actually  creating  confidence  in  the  claimed 
quality  (the  safety  case  will  contain  a  significant  contribution  from  testing).  Even  when 
one  designs  for  quality  and  a  certain  safety  attribute,  it  is  still  difficult  to  confirm  or 
establish  a  case  for  that  quality  and  attribute  without  testing.  Testing  must  be  performed 
to  a  level  that  builds  the  required  safety  case  and  meets  the  safety  risk.  Software  systems 

48  Dependability.org,  IFIP  WG-10.4,  November  2006,  http://www.dependability.org. 

49  W.C.  Lim.,  Managing  Software  Reuse,  A  Comprehensive  Guide  to  Strategically  Reengineering  the 
Organization  for  Reusable  Components,  Upper  Saddle  River,  NJ.:  Prentice  Hall  PTR,  1998,  p.  79. 
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safety  testing  must  show  the  correct  implementation  of  safety  design  requirements,  verify 
safe  implementation  of  safety-critical  functions,  and  provide  a  basis  for  qualitative  risk 
reduction  in  hazard  analyses.^*’ 

•  The  software  components  must  be  designed  with  safety  in  mind, 
consisting  of  safety  features  and  protection  mechanisms,  and  should  use  formal  semantics 
for  specifying  safety  attributes  and  safety  contracts.  This  could  be  performed  by  using  a 
formal  specification  language  to  specify  safety  requirements  and  then  designing  to  them. 
The  use  of  formal  methods  is  mandatory  in  the  development  of  certain  safety-critical 
software  and  their  use  here  would  be  valuable  in  specifying  the  requirements  in  a  precise, 
unambiguous  form.  For  example,  “The  methods  used  in  the  SRS  (safety-related  software) 
development  process  shall  include  . . . :  a)  formal  methods  of  software  specification  and 
design;  ...”5i 

•  The  component  should  comply  with  the  important  critical  success  factors 
for  reuse  quality  of  the  component.  If  a  reused  component  is  not  of  sufficient  quality,  the 
success  of  any  future  reuse  will  be  jeopardized.  This  comes  back  to  the  requirement  that  a 
reusable  component  should  be  of  high  quality  and  highly  dependable  and  that  quality  or 
dependability  be  explicitly  defined  in  terms  of  specific  quality  attributes  (sometimes 
referred  to  as  “-ilities”)  that  the  specific  safety-critical  context  will  determine.  It  is 
important  to  determine  those  attributes  and  define  them  in  a  meaningful  and  deliverable 
way.  Applicable  standards  may  be  used  to  support  the  achievement  of  the  requisite 
component  quality;  however,  it  is  important  to  realize  that  using  standards  will  not 
guarantee  the  required  quality.  Moreover,  not  using  appropriate  standards  or  processes 
will  almost  ensure  that  the  desired  quality  is  not  present. 

Safety  contracts  may  be  used  to  design  components  to  be  reused  in  safety-critical 
software.  However,  the  application  of  these  safety  contracts  is  yet  to  be  demonstrated. 
Furthermore,  adequate  tool  support  does  not  exist  to  ensure  that  these  safety  contracts  are 
binding  throughout  the  development  process. 

50  SW4582  Weapon  System  Software  Safety  Lecture  Notes,  Naval  Postgraduate  School,  2006. 

51  UK  Ministry  of  Defence,  Defence  Standard  00-55,  Requirements  for  Safety  Related  Software  in 
Defence  Equipment,  1  Aug  97. 
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D,  REUSABLE  SOFTWARE  COMPONENT  SPECIFICATION 


1.  Overview 

It  is  not  enough  to  design  a  component  for  reuse  and  believe  that  it  will  subsequently 
be  reused  just  because  it  exists  and  possesses  the  required  attributes.  Reuse  must  be  enabled 
through  appropriate  specification  of  the  component,  providing  the  ability  for  a  potential 
reuser  to  perform  a  specification  match  against  the  new  requirements. 

The  goal  of  reusable  software  component  specification  should  be  to  reveal  the 
essential  information  about  the  component  to  allow  an  effective  reuse  decision  to  be  made 
while  concealing  the  nonessential.  This  is  just  like  any  other  area  in  software  engineering 
where  the  key  is  to  find  the  right  level  of  abstraction  for  the  message  you  are  trying  to 
communicate.  In  defining  what  is  required  in  the  specification  it  is  important  to  think  of  the 
user  of  the  reusable  software  component  and  determine  what  information  is  required  to  make 
that  reuse  decision.  Furthermore,  the  potential  user  of  the  software  component  must  be  able 
to  locate  a  candidate  component.  The  question  to  be  answered  is:  “Does  the  software 
component  meet  my  requirements  and  what  are  the  risks?”  In  safety-critical  system  of 
systems  the  answer  will  not  be  simple  and  will  involve  the  composition  of  many  different 
types  of  information  on  the  component.  What  will  be  required  is  the  ability  first  to  identify 
potential  reuse  candidates  based  on  how  close  the  specification  meets  the  requirements  and 
then  to  confirm  the  requirements  match  through  further  analysis. 

2,  Software  Component  Specification 

There  are  many  ways  to  specify  a  software  component  and  completely  describe  it 
to  provide  the  desired  level  of  understandability.  The  level  of  understandability  for 
safety-critical  system  of  systems  components  is  relatively  high.  Early  work  on  specifying 
software  components  included  the  3C  model  by  Weide  et  al.52  and  Tracz,53  which  was  a 
highly  abstract  framework  model: 


52  B.W.  Weide.,  et  al.  (1991)  Reusable  software  eomponents,  Advanees  in  Computers,  Yovits,  M.  C 
(ed.),  Vol.  33,  Aeademie  Press. 

53  W.  Traez.,  The  3  Cons  of  Software  Reuse,  in  Proe  of  the  Third  Annual  Workshop  on  Software 
Reuse,  July,  Syraeuse,  NY,  1990. 
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Concept,  A  statement  of  what  a  pieee  of  software  does,  factoring  out  how 
it  does  it  (abstract  specification  of  abstract  behavior). 

Content,  A  statement  of  how  a  piece  of  software  achieves  the  behavior 
defined  in  its  concept  (the  code  to  implement  a  functional  specification). 

Context,  Aspects  of  the  software  environment  relevant  to  the  definition  of 
concept  or  content  that  are  explicitly  part  of  the  concept  or  content. 

Under  that  model,  it  could  be  still  quite  difficult  for  a  user  to  find  the  component 
sought.  Another  model  has  been  suggested  to  describe  the  software  component  and 
increase  the  transparency  of  the  information  of  a  particular  software  component  through 
an  extension  of  the  Class  Responsibility  Collaboration  (CRC)  cards  used  in  object- 
oriented  design.  This  model,  proposed  by  Riehle,^^  also  at  a  high  level  of  abstraction,  can 
be  used  to  describe  the  component  providing  more  relevant  information  for  matching 
than  the  earlier  models  of  Weide  and  Tracz. 

The  CRCCC  or  CRC^  specification  as  described  by  Riehle^^  at  the  component 
level  is: 


Component  Identifier.  Self-describing  name. 

Responsibility,  What  problem  are  we  trying  to  solve? 

Collaborations,  Identify  other  components. 

Constraints  and  Bounds,  Design  metrics  for  each  element. 

Controls,  Prevent  internal  and  external  variations,  behaving  like  a 
feedback  control  loop  with  a  (possibly  varying)  set-point.  This  also 
involves  a  clear  statement  of  the  action  to  be  taken  when  a  control 
is  violated. 


54  R.  Riehle.,  Software  Design  Metrics:  Designing  Software  Components  to  Tolerances,  ACM 
SIGSOFT  Software  Engineering  Notes,  Volume  32,  Issue  4,  Article  7,  July,  2007,  p.  1-6. 

55  Ibid.,  p.  4. 
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Extending  on  the  specifieation  models  deseribed  above  we  propose  a  new 
speeification  model  to  provide  the  necessary  information  for  specification  matching  in 
safety-critical  system  of  systems.  That  model,  the  C^RA  model,  is  described  as  follows: 

•  Component  Identifier.  This  is  the  name  of  the  component,  which  should 
be  semantically  accurate  and  conform  to  an  agreed  ontology  convention. 

•  Collaborations.  This  specifies  any  other  components  it  requires  to 
collaborate  with  to  solve  the  problem  utilizing  the  same  ontology  for  the  component 
identifier  (as  per  section  3C,  the  design  goal  is  to  keep  collaborations  to  a  minimum). 
Furthermore,  it  is  to  include  interface  specifications  for  those  collaborations. 

•  Constraints  and  Limitations.  The  constraints  and  limitations  are 
expressed  in  terms  of  design  metrics  for  each  element,  including  those  related  to  safety, 
quality  attributes,  pre  and  post  conditions,  and  invariants. 

•  Controls.  The  controls  for  the  software  component  should  describe  the 
failure  conditions,  safety  features,  protection  mechanisms,  and  any  potential  safety 
concerns,  as  well  as  the  mitigation  strategy.  The  controls  are  the  means  for  preventing 
failure  and  for  mitigating  the  hazard  causal  factors. 

•  Configurations.  This  is  a  description  of  the  set  of  possible  internal 
software  configurations  for  the  component. 

•  Responsibility.  This  is  a  description  of  what  problem  the  software 
component  will  solve  and  will  typically  be  expressed  in  functional  terms. 

•  Analysis.  This  is  the  analysis  of  all  safety  concerns  for  the  component, 
including  interface  safety  concerns.  It  also  consists  of  those  open  problem  or  safety 
reports,  any  assumptions  made  in  the  design  of  the  component,  and  any  supporting  data 
or  relevant  information  that  supports  the  safety  case  or  possible  certification. 

This  model  has  a  different  definition  of  control  to  the  Riehle  model. 

This  specification  model  is  required  in  addition  to  the  set  of  software  artifacts  that 
comprise  the  software  component  in  order  to  provide  a  complete  specification  of  the 
known  information  on  the  software  component.  The  set  of  software  artifacts  would  be 
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provided  separately  to  support  further  analysis  and  integration  of  the  eomponent  into  the 
system  and  system  of  systems  post  selection.  This  organizes  the  information  on  a 
software  component  in  a  suitable  form  to  enable  specification  matching.  The  C^RA 
specification  model  partitions  the  relevant  information  into  separate  descriptive 
categories  that  can  enable  the  initial  search  and,  along  with  the  information  contained  in 
each  of  the  software  component  artifacts,  represents  a  complete  collection  of  the 
information  for  a  component.  It  is  important  that  each  descriptive  category  provides 
sufficient  detail  to  achieve  the  initial  match  and  that  software  component  information  is 
available  to  conduct  further  analysis  in  order  to  downselect  on  the  most  appropriate 
component.  This  makes  it  easier  to  identify  for  reuse  with  a  more  complete  understanding 
of  what  it  will  do. 

To  complete  the  C^RA  specification  of  a  software  component,  an  accompanying 
ontology  is  required  so  that  proper  classification  occurs  including  naming  conventions 
and  relationships  between  entities  (composition  and  decomposition  relationships),  which 
will  reduce  duplication  and  aid  in  searching  (specification  matching).  The  ontology  will 
be  organizational  and  domain  specific  and  should  be  contained  in  policy  and  managed  by 
the  reuse  librarian  as  well  as  the  managers  of  those  areas  within  the  organization 
developing  reusable  software  components.  A  standard  ontology  among  an  industry  would 
enhance  the  ease  of  specification  matching  to  requirements  and  facilitate  more  effective 
reuse.  This  would  require  commitment  from  industry  or  system  of  systems  regulators  and 
mandate  that  component  specifications  follow  the  C^RA  format  and  a  descriptive 
ontology.  For  example,  the  FAA  in  AC20-148  requires  a  number  of  deliverables,  as 
described  in  DO-178B,  to  be  submitted  and  could  request  that  information  is  provided  in 
accordance  with  the  C^RA  format  using  a  standardized  ontology  to  provide  a  high  level 
abstraction  to  aid  their  analysis.  This  could  also  be  utilized  by  other  regulators  such  as  the 
Naval  Air  Systems  Command  for  USN  and  USMC  aviation  and  the  ADF  for  military 
aviation  in  Australia.  For  example,  within  the  aviation  industry,  operating  safety-critical 
system  of  systems  the  high  level  choices  in  the  ontology  for  potential  component 
identifiers  within  avionics  software  components  may  be:  aircraft  management,  mission 
computing,  navigation,  collision  avoidance,  radar,  sensor  systems,  data  links,  diagnostics. 
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weapon  management,  and  weapons.  The  eollaborations  seetion  of  the  C^RA  specifieation 
may  also  use  the  same  ontology  when  referring  to  the  eomponents  it  collaborates  with  to 
solve  the  problem  as  well  as  the  type  of  collaborations. 

The  component  shall  be  specified  in  a  language  and  description  model  (such  as 
UML)  that  is  in  demand,  standardized,  and  widely  understandable.  This  is  significant  in 
this  application  domain  as  certain  languages  are  better  suited  to  conveying  information 
about  safety  than  others  but  it  will  be  dependent  on  the  specific  domain  of  the  system  of 
systems  and  what  the  industry  standard  specification  language  may  be,  including  formal 
specification  languages. 

Complete  documentation  of  the  software  including  the  C^RA  is  important  to 
ensure  transparency,  understanding,  and  to  support  an  effective  reuse  decision  in  safety- 
critical  system  of  systems.  This  is  required  of  all  reusable  software  components  as  the 
code  itself  only  contains  approximately  10%  of  the  information  on  the  software. The 
C^RA  abstract  model  will  not  contain  all  relevant  information  for  all  potential  contexts  of 
use  but  it  represents  a  sound  approach  to  capturing  that  information  that  is  known  in  the 
current  context  and  providing  it  for  potential  users  of  the  reusable  component.  Potential 
future  users  may  require  more  information,  depending  on  the  exact  context  of  use.  Major 
design  decisions  should  be  recorded  in  their  respective  artifacts  with  a  complete 
description  of  the  rationale.  The  metrics  should  be  for  software  quality  and  efficiency  and 
be  specific  to  the  component’s  functionality  or  potential  use.  It  is  therefore  essential  that 
for  reusable  software  components  to  be  used  in  safety-critical  systems,  software  quality 
metrics  be  documented  (third  C  in  C^RA  specification).  Metrics  providing  indicators  of 
quality  attributes  would  be  applicable  to  the  reusable  components.  Software  quality 
metrics  are  essential  for  reusable  software  components  with  potential  use  in  safety- 
critical  systems. 

All  information  about  the  component  should  be  part  of  the  component  itself. 
Some  languages  support  automatic  documentation,  increasing  the  reusability  of  the 
software  (e.g.,  RDoc  in  Ruby).  The  documentation  on  the  reusable  software  component 

56  M.  Auguston.,  SW4540  Software  Testing  Leeture,  Naval  Postgraduate  Sehool,  Monterey,  Mareh 
26,  2007. 
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should  also  contain  information  on  certifications  achieved  (e.g.,  FAA  eertifieations  for 
airborne  software  components,  espeeially  what  level  of  certification  has  been  aehieved 
for  the  particular  registered  reusable  software  component)  and  any  open  problem  reports. 
It  is  particularly  relevant  to  reeord  whether  in  the  case  of  civil  aviation,  the  FAA  has 
aceepted  a  software  component  as  an  RSC  (Reusable  Software  Component).  This 
acceptanee  information  will  provide  potential  users  of  the  software  eomponent  with 
information  of  its  certification  baseline  and  what  may  be  required  for  their  particular 
context  of  use. 

The  C^RA  model  represents  an  effective  eomponent  specification  scheme  at  a 
high  level  of  abstraetion;  however,  all  information  of  the  software  component  should  be 
available  and  eontained  with  the  product  itself  C^RA  represents  a  good  starting  point 
that,  when  accompanied  by  an  ontology  and  division  of  eomponent  information  within, 
ean  aid  in  loeating  candidate  eomponents  for  reuse  and  thus  finding  a  specifieation  mateh 
for  the  requirements. 

E,  SAFETY  PROCESS  AND  HAZARD  ANALYSIS 

1.  Overview 

A  component  that  has  been  designed  for  reuse,  meeting  the  attributes  of  reusable 
software  components,  and  is  speeified  appropriately  (making  it  easy  to  identify  and 
locate;  and  hence  perform  speeification  matehing)  does  not  automatieally  make  it  suitable 
for  use  in  safety-eritical  system  of  systems.  Safety-eritieal  system  of  systems  are  so 
complex^^  that  each  software  component  must  be  assessed  for  suitability  in  the  eontext  of 
use  through  a  hazard  analysis  or,  in  this  speeific  ease,  a  system-of-systems  hazard 
analysis.  This  is  further  reinforeed  in  the  FAA’s  air  eireular  guidance  (AC20-148)  on 
reusable  software  eomponents  (RSC)  where  for  acceptanee  as  an  RSC  and  eaeh 
subsequent  reuse  requires  that  there  be  no  safety  and  other  eoneems  before  approval, 
although  it  is  not  speeified  how  this  will  be  done. 

57  The  reasons  for  this  complexity  are  largely  as  a  result  of  their  not  being  one  controlling  entity  over 
all  within,  the  fact  that  the  systems  were  not  usually  designed  to  operate  in  a  system  of  systems  and  that 
there  are  many  possible  configurations  and  interfaces  between  concomitant  systems. 
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Having  quality  well  specified  software  components  does  not  guarantee  safe 
operation  in  an  environment  and  state  space  that  is  significantly  large  and  contains 
additional  hazards  to  those  represented  by  the  sum  of  all  concomitant  system  hazards  in 
the  system  of  systems.  These  additional  hazards  are  called  emergent  hazards  and  need  to 
be  identified,  analyzed,  and  treated  along  with  revisiting  and  analyzing  those  existing 
system  hazards.  An  emergent  hazard  is  a  hazard  that  may  occur  within  a  system  of 
systems  that  is  not  attributable  to  a  single  system. 

A  system-of-systems  hazard  is  any  hazard  that  may  occur  within  a  system  of 
systems.  The  system-of-systems  hazards  or  hazard  space  consists  of  those  hazards 
attributable  to  the  individual  systems  of  the  system  of  systems  and  emergent  hazards.  A 
system-of-systems  hazard  analysis  is  essential  before  an  effective  reuse  decision  is  made 
on  a  software  component  for  use  in  a  safety-critical  system-of-systems.  This  is  required 
once  a  specification  match  is  achieved  and  the  software  component  incorporated  into  a 
system.  When  a  software  component  is  considered  for  reuse  in  this  environment,  the 
system-of-systems  hazard  analysis  must  be  updated  including  the  analysis  of  the  system 
hazards  as  well  as  any  potential  emergent  hazards  that  could  arise  through  the  use  of  the 
system  containing  the  reused  software  component.  The  reassessment  of  system  hazards  as 
a  result  of  the  new  component  is  defined  and  documented  in  MIL-STD-882D  and  the 
system  safety  handbook;^^  however,  the  emergent  hazard  analysis  process  is  relatively 
immature.  The  identification  of  system-of-systems  hazards  involves  a  collaborative  effort 
on  behalf  of  all  program  members  and  stakeholders  in  the  system  of  systems,  just  as  it 
does  in  the  identification  of  system  hazards;  however,  in  this  new  context  that 
collaboration  requires  effective  management  to  ensure  a  comprehensive  set  of  hazards  is 
identified  and  effectively  treated.  A  system-of-systems  hazard  ontology  is  required  to 
assist  in  considering  all  potential  hazard  types,  providing  consistency  and  for  providing  a 
starting  point  for  the  emergent  hazard  analysis  part  of  the  system-of-systems  hazard 
analysis.  A  detailed  ontology  will  provide  an  abstract  description  of  the  hazard  type  and 


58  National  Aeronautics  and  Space  Administration.  System  Safety  Handbook  (DHB-S-001).  Dryden 
Research  Flight  Center,  Edwards,  CA,  1999. 
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assist  in  ensuring  that  all  potential  hazard  types  are  investigated  and  analyzed  to  the 
extent  possible  given  projeet  eonstraints  and  the  system  of  systems  safety  requirements. 

When  a  decision  is  made  to  reuse  software  in  safety-critical  system  of  systems  the 
system-of-systems  hazard  analysis  needs  to  be  updated.  It  is  possible  to  identify  system 
hazards  as  a  result  of  the  reuse  in  the  system(s)  containing  the  reused  software  following 
the  process  defined  in  MIL-STD-882D  or  adapting  the  AS/NZS  4360  risk  management 
standard;  however,  not  all  hazards  will  be  considered  using  that  process  alone.  The 
system  hazards  in  the  new  context  following  reuse  will  likely  involve  those  from  the 
previous  system  hazard  analysis  and  will  provide  a  good  starting  point  for  the  new  hazard 
analysis.  The  goal  in  the  case  of  reusing  software  is  to  update  the  system-of-system 
hazard  analysis  by  updating  the  system  hazard  analysis  and  the  emergent  hazard  analysis. 
That  update  may  include  new  system  hazards  and  emergent  hazards  that  must  be 
identified  in  the  first  instance. 

The  system  safety  process  and  the  risk  management  process  are  very  similar,  both 
starting  with  the  identification  of  their  respective  elements  followed  by  analysis  and  a 
way  of  treating  those  elements.  The  risk  management  process  identified  in  AS/NZS  4360 
is  more  iterative,  involving  the  monitoring,  reviewing,  communicating  and  consulting  of 
risk  information  throughout  the  process  than  that  defined  in  MIL-STD-882D.  It  is  the 
identification  part  in  the  process  that  is  the  most  difficult  because  it  is  often  not  easy  to 
identify  all  risks,  hazards,  or  potential  risks  and  hazards.  If  the  risks  or  hazards  are  not 
identified,  then  there  is  nothing  that  can  intentionally  or  consciously  be  done  to  treat 
them.  Furthermore,  it  is  often  the  identification  part  of  the  process  that  is  the  entry  point 
for  risks  or  hazards  and  if  missed  here,  they  will  not  be  considered.  This  is  further 
exacerbated  in  a  system-of-systems  context  because  there  are  emergent  hazards  that 
cannot  be  attributed  to  any  one  system  in  isolation.  Therefore,  a  technique  that  just  sums 
those  system  hazards  within  the  safety-critical  system  of  systems  will  omit  an  important 
and  significant  category  of  hazards.  Ways  to  overcome  the  identification  problem  are  to: 
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•  Use  a  well  developed  ontology  of  hazards  or  hazard  eategories  and  apply  a  hazard 
analysis  process  to  each  category.  This  will  serve  to  identify  the  high  level 
abstract  hazards  that  could  possibly  exist  and  allow  for  exploration  in  more  detail 
in  each  category,  through  hazard  decomposition,  considering  the  impact  of  the 
addition  of  the  new  component. 

•  Brainstorm  or  use  the  collaboration  of  all  stakeholders  as  a  potential  source  of 
hazard  information  and  empower  them  to  identify  hazards  in  their  own  area  for 
consideration  by  the  system  safety  team. 

•  Utilize  safety  experts.  This  is  required  in  most  system  safety  efforts.  System 
safety  experts  or  team  members  are  essential  members  of  the  development  and 
operational  team  through  the  input  of  safety  information  into  the  process; 
however,  they  do  not  provide  a  systematic  way  of  identifying  all  hazards. 
Furthermore,  they  do  not  necessarily  have  expertise  in  areas  where  hazards  may 
exist.  They  are  not  the  panacea  to  the  identification  problem  but  serve  as  an 
essential  member  and  part  of  the  solution. 

It  is  the  hazard  identification  problem  that  is  the  most  important  because  once 
identified,  hazards  can  be  considered  and  tracked  and  the  appropriate  treatment  provided 
in  the  right  form  at  the  right  time. 

When  a  software  component  or  artifact  is  to  be  reused,  the  system-of-systems 
hazard  analysis  should  be  revisited  and  updated  to  include  the  new  component  and  its 
system.  One  should  also  revisit  the  emergent  hazards  analysis  and  consider  the  emergent 
hazard  categories  for  new  hazards. 

A  candidate  process  for  conducting  system-of-systems  hazard  analyses  that 
incorporates  software  reuse  is: 

1 .  Establish  the  context  or  environment  for  the  system  of  systems. 

2.  Identify  all  systems  in  the  system  of  systems. 
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3.  Conduct  the  system  safety  proeess  as  defined  in  MIL-STD-882D  or  similar 
standard  sueh  as  AS/NZS  4360  to  identify,  analyze,  evaluate,  and  treat  all 
system  hazards  ineluding  those  of  the  system(s)  eontaining  the  reused 
software. 

4.  Define  the  system-of-systems  arehiteeture. 

5.  Identify  the  emergent  hazards  of  the  system  of  systems  using  a  suitable 
teehnique  based  on  a  ontology  of  hazards  (sueh  as  those  partially  identified  by 
Redmond^^  to  inelude  reconfiguration,  integration,  and  interoperability 
hazards  at  a  high  level  of  abstraction)  to  assist  in  considering  all  the  potential 
hazard  types  and  their  speeifics  based  on  the  system-of-systems  arehiteeture. 
It  is  essential  to  utilize  stakeholder  collaboration  and  safety  experts  as  part  of 
this  proeess. 

6.  Analyze  emergent  hazards. 

7.  Evaluate  the  mishap  risk. 

8.  Treat  the  mishap  risks. 

9.  Evaluate  the  residual  mishap  risk  (and  eompare  with  the  aecep table  risk). 

The  proeess  involves  eontinual  feedback,  review,  monitoring,  eommunication  and 
eonsultation  of  hazard  and  risk  information  and  continues  until  the  mishap  risk  reaehes  an 
aeeeptable  value  determined  by  the  appropriate  governing  body  (or  regulator)  of  the 
system  of  systems.  Eurthermore,  the  proeess  is  iterative  in  nature  and  not  entirely 
sequential.  Step  3,  the  system  safety  proeess,  should  be  performed  in  parallel  with  steps 
4,  5,  and  6  with  eollaboration  and  eommunieation  between  them  to  ensure  sharing  of 
relevant  hazard  information.  This  proeess  involves  the  monitoring,  reviewing, 
eommunieating,  and  eonsulting  of  risk  information  throughout  the  proeess  as  per  the 
AS/NZS  standard. 


59  P.  Redmond.,  A  System  of  Systems  Interface  Hazard  Analysis  Technique,  Master’s  Thesis,  Naval 
Postgraduate  School,  Monterey,  CA,  March  2007,  p.  33. 
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F.  METRICS 

1.  Overview 

An  important  part  of  the  information  about  any  software  eomponent  and  program 
activity  are  the  relevant  metrics.  This  section  introduces  those  metrics  of  interest  when 
developing  software  for  reuse  in  safety-critical  system  of  systems  and  those  metrics 
relevant  to  measuring  the  success  of  a  reuse  program.  In  the  C^RA  specification  model, 
these  metrics  should  be  made  available  to  enable  future  reuse  (as  well  as  evolution)  and 
should  be  specified  within  the  Constraints  and  Limitations  element  of  the  model. 

2.  Software  Safety  Metrics 

To  minimize  risk  (safety  or  otherwise)  and  increase  the  chance  of  a  successful 
outcome,  quantitative  support  for  management  decision  making  is  required;  that  is 
provided  through  effective  metrics.  Metrics  are  an  extension  of  measurements  when 
provided  within  context,  enabling  greater  interpretation  and  understanding  of  what  is 
occurring.  They  are  indicators  that  provide  the  impetus  for  control  of  what  is  of  value. 

Software  safety  cannot  be  proven  or  predicted  due  to  environmental  uncertainty 
and  because  exhaustive  testing  is  infeasible.  Even  if  all  potential  hazards  are  identified, 
one  can  only  demonstrate  that  you  have  not  found  the  software  exhibiting  any  behavior 
that  could  result  in  a  hazard,  not  that  the  software  is  free  from  conditions  that  will  result 
in  a  hazard.  Formal  methods,  which  are  the  software  development  activities  that  employ 
mathematically  based  techniques  for  describing,  reasoning  about,  and  realizing  system 
properties,  expressed  using  formal  languages^o  not  reveal  the  absence  of  a  safety 
requirement.  Software  safety  metrics  will  not  tell  us  whether  the  system  is  safe,  but  they 
can  provide  indicators  of  potential  safety  problems  and  risks.  Software  safety  risk  metrics 
are  intended  to  support  detection  and  analysis  of  software-related  safety  issues  in  a  timely 
manner  and  make  potential  risks  visible.  Furthermore,  they  can  be  used  in  developing  the 


60  D.  Drsinsky.,  J.B.  Michael.,  M.  Shing.,  The  Three  Dimensions  of  Formal  Validation  and 
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safety  case  for  the  software  and  in  providing  quantitative  evidence  to  regulatory 
authorities.  The  organizational  use  of  metrics  can  be  characterized  by  the  CMMI  process 
maturity  level  of  that  organization. 

Most  of  the  work  in  deriving  software  safety  metrics  is  based  on  the  Goal, 
Question,  Metric  (GQM)  methodology  developed  by  Basil!  and  Weiss,  which  uses  a 
general  process  to  determine  effective  metrics.  That  general  process  involves: 

1 .  Identification  of  information  needs. 

2.  Interpretation  of  an  information  need  as  being  within  an  information 
category. 

3.  Identification  of  measurable  concepts  within  each  information  category. 

4.  Identification  of  prospective  measures,  associated  with  each  measurable 
concept. 

This  approach  to  determine  effective  metrics  ensures  the  rationale  behind  the 
metric  exists  and  that  what  is  subsequently  measured  has  value  and  forms  an  aid  to 
effective  decision  making  and  control. 

Reliability,  an  important  software  quality  metric  and  sub-element  of 
dependability,  can  be  used  as  an  indirect  indicator  of  safety,  with  caution.  Although 
orthogonal  dimensions  of  dependability,  they  are  often  erroneously  equated.  Reliability  is 
defined  as  the  probability  that  an  item  will  perform  a  required  function,  under  stated 
conditions,  for  a  stated  period  of  time. ^2  Safety  is  the  probability  that  conditions  that  can 
lead  to  a  mishap  (hazards)  do  not  occur,  whether  or  not  the  intended  function  is 
performed.  In  general,  reliability  requirements  are  concerned  with  making  a  system 
failure  free,  whereas  safety  requirements  are  concerned  with  making  it  mishap  free. 
These  are  not  congruent  goals  and  are  therefore  not  synonymous.  Reliability  is  concerned 


61  V.  Basil!.,  D.  Weiss.,  A  Methodology  For  Colleeting  Valid  Software  Engineering  Data,  IEEE 
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with  every  possible  software  fault, ^3  whereas  safety  is  only  eoncemed  with  those  faults 
that  may  result  in  actual  system  hazards.  Not  all  software  faults  cause  safety  problems, 
and  not  all  software  that  functions  according  to  specification  is  safe.  Severe  mishaps  have 
occurred  while  something  was  operating  exactly  as  intended,  that  is  without  failure. 
Improving  reliability  will  not  necessarily  improve  safety.  It  will  depend  on  where  the 
reliability  improvement  is  made.  Improving  reliability  by  removal  of  faults  or  preventing 
the  propagation  of  faults  may  not  remove  or  prevent  propagation  of  those  faults  that  lead 
to  safety  related  failures  and  thus  not  improve  safety  at  the  same  time.  If,  however,  all 
safety  requirements  are  in  the  software  specification,  then  reliability  can  provide  a  more 
accurate  predictor  or  indicator  of  safety.  If  reliability  is  improved  in  the  area  of  safety- 
critical  software  and  all  safety  requirements  are  included,  an  increase  in  safety  will  result. 
Reliability  of  the  software  component  and  its  system  is  important;  however,  it  should  be 
monitored  and  analyzed  separately  from  safety,  when  ensuring  system  dependability 
requirements  are  achieved. 

The  identification  and  implementation  of  safety  requirements  is  a  key  function  in 
system  and  software  safety.  All  software  safety  requirements  are  to  be  met  in  the  design 
and  implementation  of  the  software  and  must  be  verified:  each  safety  requirement  must 
have  a  test  case  or  cases  associated  with  them.  For  verification  there  needs  to  be  a 
mapping  between  the  safety  requirements  and  test  cases  with  this  mapping  reflected  in 
the  Software  Safety  Requirements  Traceability  Matrix. ^4  a  potentially  useful  metric  to 
determine  whether  verification  activities  have  been  identified  for  the  safety  requirements 
is  the  number  of  safety  requirements  unlinked  to  test  cases  (SRUTC).^^  If  this  value  does 
not  tend  to  approach  zero  over  time,  then  the  safety  risks  are  not  being  identified  as 
requiring  testing  or  verification. 


63  Fault  in  this  case  refers  to  a  defect  within  the  system. 
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If  f(x)  is  the  Safety  Requirements  Unlinked  to  Test  Cases  (SRUTC)  and  x  is  time 
to  release  of  the  software,  then: 

lim  f(x)  =  0 
x^O 

Equation  1 :  Desired  Value  of  SRUTC  Over  Time 

SRUTC  is  most  useful  during  the  requirements  analysis  and  design  phases  where 
it  is  important  that  a  means  of  verifieation  has  been  established  for  eaeh  safety 
requirement.  SRUTC  ean  ensure  that  when  a  safety  requirement  is  identified  and 
analyzed,  it  is  written  in  a  manner  that  aids  testing  and  plans  for  proof  of  it  being  met. 

Another  similar  metrie  that  we  propose  that  is  available  later  in  the  system 
lifecyele  is  the  safety  requirements  demonstration  metrie  (SRDM),^^  whieh  is  obtained 
by  dividing  the  total  number  of  separately  identified  safety  requirements  in  the  software 
requirements  speeifieation  (SRS)  that  have  been  sueeessfully  demonstrated  by  the  total 
number  of  separately  identified  safety  requirements  in  the  SRS.  Ideally  the  SRDM  should 
be  equal  to  one,  indieating  that  the  implementation  of  eaeh  safety  requirement  has  been 
tested. 

SRDM  =  Total  Number  of  Demonstrated  Safety  Requirements 
Total  Number  of  Safety  Requirements 

Equation  2.  Software  Requirements  Demonstration  Metric 

SRDM  differs  from  SRUTC  in  that  the  former  monitors  the  demonstration  of  the 
safety  requirements  whereas  the  latter  ensures  that  the  verification  activity  has  been 
identified. 

To  place  the  required  emphasis  and  priority  on  safety,  it  is  essential  in  the 
development  of  safety-critical  software  that  an  adequate  proportion  of  the  requirements 
set  consists  of  safety  requirements.  Thus  the  question  that  could  be  asked  here  is:  “Are 
there  a  reasonable  number  of  software  safety  requirements  being  identified?”  The  metric 


66  Adapted  from  the  requirements  demonstration  metric  in  IEEE  standard  for  Software  Quality 
Assurance  Plans,  730-1998,  p.  3. 
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could  be  Percent  Software  Safety  Requirements  (PSSR),^^  which  is  the  pereentage  of 
software  safety  requirements  relative  to  the  total  number  of  software  requirements.  If  the 
number  of  identified  software  safety  requirements  is  not  “reasonable”  relative  to  the 
platform  family  or  in  line  with  system  safety  in  general,  this  would  represent  a  risk.  If 
there  are  too  few  software  safety  requirements,  this  would  represent  a  safety  risk  and 
alternatively  too  many  could  result  in  eost  and  sehedule  risks  for  the  projeet  or 
development.  The  assessment  of  reasonableness  would  be  based  on  heuristics  derived 
from  past  experience  in  the  development  of  safety-critical  software  and  on  engineering 
judgment  of  what  would  make  a  reasonable  pereentage  given  the  potential  hazards  and 
risks.  This  metrie  has  the  most  relevance  during  requirements  and  analysis  activities  of 
the  software  life  cycle,  where  an  early  indieation  of  whether  safety  is  being  adequately 
eonsidered  in  the  development  is  available. 

PSSR=  Number  of  Software  Safety  Requirements 
Number  of  Software  Requirements 

Equation  3.  Pereent  Software  Safety  Requirements 

Other  safety  metrics  of  value  are  related  to  hazard  identifieation  and  provides 
answers  to  the  following  questions: 

•  Have  a  reasonable  number  of  software  safety  hazards  been  identified? 

•  Are  causes,  controls  and  verifications  being  generated  over  time? 

•  Does  every  cause  have  at  least  one  control? 

•  Does  every  control  have  at  least  one  verifieation  to  test  that  the  control  has 
been  implemented? 

The  subsequent  metrics^^  are: 
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•  Percent  Software  Hazards  (PSH),  which  is  the  number  of  software  safety 
hazards  divided  by  the  number  of  system  safety  hazards.  If  number  of  identified  hazards 
is  not  “reasonable”  then  there  are  problems  with  the  hazard  management  and  analysis 
process  for  software. 

PSH  =  Number  of  Software  Safety  Hazards 
Number  of  System  Safety  Hazards 

Equation  4.  Percent  Software  Hazards 

This  metric,  like  the  Percent  Software  Safety  Requirements,  will  indicate  whether 
software  hazards  are  receiving  the  appropriate  attention  compared  to  all  system  safety 
hazards.  This  metric  also  has  most  relevance  during  requirements  and  analysis  activities 
of  the  software  life  cycle  to  provide  early  consideration  and  indication  of  whether 
software  safety  hazards  are  being  appropriately  identified  in  order  for  them  to  be 
managed.  This  metric  should  also  be  updated  throughout  the  software  life  cycle  to  keep 
the  safety  case  current  and  to  ensure  software  safety  hazards  are  being  appropriately 
considered  when  the  system  and  software  undergoes  changes  and  evolution. 

•  Controls  with  causes  (CwC)  is  the  number  of  software  safety  hazard  causes  for 
which  there  is  a  control  divided  by  the  number  of  causes  for  all  software  safety  hazards. 
If  there  are  causes  without  controls  then  there  are  problems  with  the  hazard  management 
process  for  software.  This  metric  is  most  relevant  during  the  analysis,  design,  and 
implementation  phases,  where  software  safety  hazard  controls  are  designed  into  the 
software  component  and  system. 

CwC  =  Number  of  Causes  with  a  Control 

Total  Number  of  Causes  for  all  Hazards 

Equations.  Controls  with  Causes 

•  Verifications  with  controls  (VwC)  is  the  number  of  controls  for  which  there  is  a 
verification  divided  by  the  number  of  controls  for  all  hazard  causes.  If  there  are  controls 
without  verification,  then  there  are  problems  with  the  hazard  management  and  analysis 
process  for  software. 
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VwC  =  Number  of  Controls  for  which  there  is  a  Verification 
Total  Number  of  Controls  for  all  Causes  of  Hazards 

Equation  6.  Verifications  with  Controls 

This  metric  follows  on  from  CwC,  where  it  is  essential  for  software  assurance  that 
the  hazard-cause  control  is  associated  with  an  appropriate  verification.  This  metric  is 
most  relevant  during  the  analysis,  design,  and  implementation  phases,  where  software 
safety  hazard  controls  will  be  linked  to  verification  activities.  These  verifications  will 
subsequently  guide  testing  of  the  software  component  to  ensure  that  the  controls 
implemented  perform  as  intended  and  reduce  the  safety  risk. 

Another  metric  identified  by  Basili  et  al.  within  hazard  management  that  can  be  a 
useful  indicator  of  safety  answers  the  question:  “Is  the  number  of  open  software  hazard 
components  (causes,  controls,  and  verifications)  shrinking  over  time?”  What  is  desirable 
is  for  the  number  of  open  software  causes  and  controls  to  be  closing  over  time  to  indicate 
that  hazards  are  progressively  being  brought  under  acceptable  control.  This  metric,  called 
the  Hazard  Cause/Control  Closure  Evolution  (HCCE),^^  is  a  three  point  moving  average 
of  the  set  of  open  causes  and  controls  at  three  consecutive  time  intervals.  This  metric 
indicates  relative  performance  of  closing  hazard  causes  with  controls  and  verification 
with  respect  to  previous  time  periods  (rather  than  just  looking  at  the  number  of  open 
causes  in  isolation).  If  greater  than  one,  this  would  suggest  that  hazard  causes  or  controls 
are  opening  faster  than  they  are  closing.  What  is  important  here  is  to  understand  the 
relationship  between  the  metric  and  the  stage  in  the  lifecycle  the  software  is  in.  Early  on 
values  greater  than  one  are  acceptable;  however,  at  some  point  the  value  should  remain 
below  one.  The  value  will  also  depend  on  the  type  of  system  developed  and  its 
environment,  although  at  some  stage  it  would  be  expected  that  hazard  causes  or  controls 
will  be  opening  faster  than  they  are  closing  (early  in  software  life  cycle).  A  decline  in  this 
value  over  time  will  suggest  that  hazard  causes  and  their  controls  are  being  brought  under 
control  and  be  representative  of  system  maturity  and  context  of  use  stability. 
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Another  metric  identified  by  Basili  et  al.  determines  whether  the  software  being 
developed  is  receiving  the  appropriate  level  of  rigor  for  its  software  risk.  Level  of  rigor  is 
defined  as: 

The  amount  of  requirements  analysis,  development  discipline,  testing,  and 
configuration  control  required  to  mitigate  the  potential  safety  risks  of  the 
software  component, 

Example  level  of  rigor  metrics  are  Percent  Requirements  Level  of  Rigor 
(PRLOR)  and  Percent  Code  Level  of  Rigor  (PCLOR),^i  which  compares  whether  the 
level  of  rigor  employed  is  what  is  expected  of  software  with  a  certain  level  of  autonomy 
or  control  categorization.  This  is  similar  to  ensuring  that  the  software  receives  the 
appropriate  level  of  analysis  and  testing  for  its  control  category  according  to  the  software 
hazard  risk  index  within  the  software  risk  assessment  matrix.  An  example  software  level 
of  rigor  and  what  is  expected  at  each  software  level  is  contained  in  Appendix  A.  Another 
example  of  a  similar  approach  is  the  software  life  cycle  process  objectives  and  outputs  by 
software  level  provided  in  DO-178B  Software  Considerations  in  Airborne  Systems  and 
Equipment  Certification.^^  jt  important  to  have  a  metric  that  indicates  whether  the 
appropriate  rigor  or  attention  is  given  to  the  category  of  software.  That  metric  can  be 
expressed  in  percentage  terms  against  what  is  expected.  If  these  percentages  are  not 
within  reasonable  values,  then  safety-critical  software  might  not  be  developed  to  the 
appropriate  level  nor  receive  the  appropriate  level  of  attention  during  development. 
Additionally,  if  the  percentage  is  too  high,  this  could  increase  the  cost  and  schedule  risk 
for  the  project.  This  type  of  metric  is  relevant  throughout  software  development  and  can 
be  used  during  all  activities  in  the  development  of  software  for  safety-critical  systems. 
This  metric  also  appears  to  be  applying  a  CMMI  type  approach  to  the  development  of 
safety  critical  software  and  ensuring  that  certain  activities  occur  depending  on  the  level  of 
software  being  developed.  There  is  an  underlying  assumption  in  this  metric  that  the 
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development  effort  should  depend  on  the  level  of  eritieality  of  the  software.  There  should 
also  be  an  industry  wide  aeeepted  best  practice  for  what  that  effort  should  be  when 
developing  safety-critical  software.  As  described  later  in  this  section,  the  +SAFE^3 
extension  to  the  CMMI  provides  an  example  of  this  type  of  approach. 

It  is  also  essential  to  determine  whether  software  safety  defects  are  being 
resolved.  A  relatively  simple  metric  can  be  applied  here  for  safety  defects  that  is  a 
measure  of  the  number  of  safety  defects  and  then  a  list  of  them  in  priority  order.  This  will 
assist  in  the  progress  of  resolving  safety  defects  and  provide  an  indicator  of  safety  for  the 
software.  Furthermore,  safety  defect  density  can  indicate  how  effectively  the 
development  designed  software  that  was  free  of  safety  defects.  This  metric  could  also  be 
used  to  compare  projects  and  create  a  baseline  for  organizational  process  improvement  in 
the  removal  of  safety  defects.  This  metric  is  applicable  throughout  verification  and 
testing  where  the  defects  are  identified  and  the  test  results  used  during  both  redesign  and 
re-coding  efforts. 

Another  approach  to  minimizing  risk  including  safety  risk  is  the  application  of  the 
SEI  CMMI.  The  CMMI  characterizes  an  organization  based  on  the  maturity  of  its 
processes  on  a  scale  of  one  to  five,  from  initial  (1)  to  optimized  (5).  The  premise 
underlying  CMMI  is  that  improved  and  mature  processes  result  in  higher  quality  and  risk 
reduction.  Contracting  with  an  organization  at  a  higher  maturity  level  on  the  CMMI 
model  reduces  development  risk  and  increases  the  chances  of  a  successful  outcome.  The 
Defence  Materiel  Organisation  (DM0)  in  Australia,  users  of  the  CMMI  to  improve  its 
acquisition  and  maintenance  of  software-intensive  systems,  recognized  that  the  model 
may  inadequately  address  the  specialized  needs  relating  to  safety-critical  systems  and  so 
developed  a  safety  extension  in  conjunction  with  the  Software  Verification  Research 
Centre  (SVRC)  to  the  CMMI  called  “+SAFE”.^4  aim  of  this  extension  is  to  identify 
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the  safety  strengths  and  weaknesses  of  produet  and  service  suppliers,  and  to  address 
identified  weaknesses  early  in  the  acquisition  process.^^  The  safety  extension  was 
developed  so  that  CMMI  appraisers  and  users  can  become  familiar  with  the  structure, 
style,  and  content  provided  to  reduce  dependence  on  safety  domain  expertise. 

This  extension  to  CMMI  consists  of  two  safety  process  areas  added  to  CMMI- 
DEV  to  provide  an  explicit  and  focused  basis  for  appraising  or  improving  an 
organization’s  capabilities  for  providing  safety-critical  products.  Those  two  safety 
process  areas  are  Safety  Management  within  the  Project  Management  CMMI  category 
and  Safety  Engineering  within  the  Engineering  CMMI  category.  It  essentially  provides  a 
process  for  developing  safety-critical  products,  and  a  metric  or  measurement  would  be 
how  well  does  the  organization’s  process  for  developing  safety-critical  software  follow 
that  defined  by  the  +SAEE  extension.  In  other  words,  the  metric  would  be  representative 
of  and  answer  the  question  of  “how  close  to  this  benchmark  is  the  organization?”  The 
metric  used  is  the  integration  of  the  percent  satisfaction  of  the  specific  goals  within  each 
process  area  and  CMMI  category.  The  closer  the  organization  is  to  the  +SAEE  process 
the  greater  the  organization’s  understanding  of  the  safety  domain  and  the  increased 
likelihood  that  the  organization  will  be  able  to  deliver  safe  software.  This  information 
would  not  only  be  useful  in  the  development  of  safety-critical  software,  but  it  also 
provides  evidence  for  input  to  the  safety  case  for  the  software  (and  the  parent  system)  and 
assists  in  making  assessments  of  an  organization’s  capability  for  developing  safety- 
critical  software. 

The  work  of  Jones  proposes  a  key  node  safety  metric  and  a  safety  improvement 
algorithm.  The  key  node  safety  metric  predicts  the  relative  safety  between  different 
versions  of  software  modules  using  a  heuristic  analysis  of  fault  tree  structure  and 
calculates  a  value  based  on  the  fault  tree  properties  such  as  key  node  height,  size  of  key 
node  sub-trees,  and  the  number  of  key  nodes.  The  safety  improvement  algorithm  provides 
an  objective  method  of  improving  a  system’s  safety  by  determining  which  components 
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need  improvement  and  by  what  amount  in  order  to  aehieve  the  desired  inerease  in  safety. 
The  algorithm  also  provides  an  estimate  of  resouree  requirements  in  man-hours  to  meet 
the  safety  requirement.  The  key  node  safety  metrie  has  much  promise  and  benefit  as  it  is 
based  on  causal  factors  and  the  relationships  between  events  that  result  in  hazards. 
Moreover,  as  during  hazard  analysis,  fault  trees  are  prepared  incorporating  this  metric 
would  be  easy  as  it  could  leverage  off  the  existing  fault  trees  and  involve  defining  the 
properties  of  those  already  identified  key  nodes.  This  metric  has  potential  value  in 
enabling  decisions  on  safety  of  designs,  minimizing  the  potential  for  causal  factors  to 
propagate,  and  in  building  in  fault  tolerance.  This  metric  requires  testing  on  whether  it 
benefits  the  design  and  safety  assessment  of  a  safety-critical  software-intensive  system. 
With  this  metric,  a  pilot  project  should  be  used  to  validate  it  and  to  test  whether  it 
effectively  supports  decision  making.  If  this  metric  is  validated,  it  could  have  a 
significant  impact  on  the  evolution  and  improvement  of  software  components  in  safety- 
critical  system  of  systems. 

Test  metrics  are  also  relevant  to  software  safety  assessments.  The  test  coverage 
and  results  will  be  a  source  of  metrics  information  to  determine  the  safety  of  the  software. 
The  relevant  metrics  include  test  case  criteria,  such  as  statement,  decision,  condition,  and 
define -use  pair  and  usage-based  coverage.  It  would  be  preferable  to  conduct  higher 
criteria  testing  on  the  safety-critical  software  and  that  software  that  has  successfully 
passed  those  higher  criteria  testing  can  be  inferred  as  being  safer.  The  level  of  testing  and 
its  coverage  will  depend  on  the  resources  available  and  the  requirements  of  any 
regulatory  agency.  The  degree  of  test  coverage  of  safety  critical  software  should  be 
adequately  determined.  If  software  testers  are  aware  of  the  need  for  additional  test 
coverage  of  safety  critical  functions,  these  will  be  incorporated  into  the  routine  testing 
which  will  then  influence  developers  to  design  in  safety  as  they  will  be  aware  of  the 
increase  in  quality  required  of  their  software. 

Although  the  above  software  safety  metrics  appear  to  be  effective  in  theory,  they 
should  be  validated  in  a  realistic  environment.  A  number  of  the  metrics  also  rely  on 
subjective  assessments,  baselines,  or  heuristics  to  determine  what  is  a  reasonable  value 
for  the  metric,  so  the  application  of  these  may  take  time  and  a  number  of  developments  to 
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achieve  optimal  outeomes  (i.e.,  determination  of  what  “reasonable”  values  are).  These 
software  safety  metrics  add  value  to  the  development  and  provide  an  important  indicator 
of  software  safety  and  support  management  deeisions.  They  are  also  important  safety 
indicators  for  designing  reusable  software  components  for  use  in  safety-critical  system  of 
systems. 

It  is  important  not  to  act  on  metrics  information  alone,  to  understand  that  they  are 
indieators  of  potential  safety  issues,  and  to  use  them  as  triggers  for  further  analysis, 
which  should  be  inherently  available  in  the  eomponent.  In  the  applieation  of  metries  it  is 
important  that  the  essential  ones  be  implemented  (those  that  provide  the  best  indication  of 
safety)  and  the  colleetion  methods  resourced.  It  is  essential  to  focus  on  the  key  indieators 
and  not  try  to  eollect  as  much  information  as  you  can  as  this  will  only  distill  that 
information  that  is  critical.  This  needs  to  also  be  balanced  with  the  measurements  already 
conducted  so  that  the  safety  metries  collection  process  integrates  seamlessly  with  other 
metrics  processes. 

There  are  other  metrics,  such  as  those  identified  in  IEEE  Standard  for  Software 
Quality  Assurance  Plans,  730-1998  (braneh  metric,  decision  point  metric,  domain  metric, 
error  message  metric)  which  provides  minimum  aeceptable  requirements  for  preparation 
and  eontent  of  Software  Quality  Assuranee  Plans  (SQAPs)  applieable  to  the  development 
and  maintenance  of  eritical  software;  however,  they  may  relate  more  to  the  aggregation 
of  quality  attributes  as  opposed  to  the  more  safety  focused  metrics  described  here. 
Eurthermore,  this  standard  provides  the  minimum  requirements  for  SQAPs  and  would 
thus  be  expeeted  to  be  applied  by  most  organizations  developing  and  maintaining  critical 
software.  What  is  required  are  metrics  that  are  more  focused  on  safety  and  descriptive  of 
the  safety  of  the  software. 

3,  Summary  of  Software  Safety  Metrics 

Table  3  represents  a  summary  of  the  software  safety  metrics  identified  herein, 
their  relative  ranking  of  importanee  (usefulness)  in  designing  safe  software  and  the  part 
of  the  software  lifeeyele  where  they  are  most  relevant. 
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Rank 

Software  Safety 
Metric 

Description 

Expected  & 
Preferred  Values 

Software  Life 
Cycle  Activity 
with  most 
Relevance 

1 

Percent  Software 
Safety 

Requirements 

(PSSR) 

The  number  of  software  safety 
requirements  divided  by  the 
number  of  software  requirements 

Reasonable  Value 
based  on  heuristics 
and  experience 

Requirements 

2 

Percent  Software 
Hazards  (PSH) 

The  number  of  software  safety 
hazards  divided  by  the  number  of 
system  safety  hazards 

Reasonable  Value 
based  on  heuristics 
and  experience 

Requirements 

3 

SEI  CMMI 

+SAFE  Extension 

A  process  for  developing  safety 
critical  products  and  a  measure  of 
how  close  to  the  standard  a 
developer  is 

100%  meaning  that 
the  organization 

complies  with  all 
aspects  of  the 

preferred  process 

Assessed  before 

development 

begins 

4 

Percent  Level  of 
Rigor  (or  analysis 
and  testing  effort) 

Compares  the  level  of  rigor 
employed  to  what  is  expected  of 
software  with  a  certain  level  of 
autonomy  or  control 
categorization 

100% 

Design  and 

Implementation 

5 

Software 
Requirements 
Unlinked  to  Test 
Cases  (SRUTC) 

The  number  of  safety 
requirements  unlinked  to  test 
cases 

0  or  approaching 
zero 

Requirements, 
Analysis,  and 
Design 

6 

Open  Software 

Safety  Defects 

The  number  of  open  software 
safety  defects  with  priority 

0 

Design, 

Implementation, 
and  Testing 

7 

Controls  with 

Causes  (CwC) 

The  number  of  causes  with  a 
control  divided  by  the  total 
number  of  causes  for  all  hazards 

1 

Design  and 
Implementation 

8 

Verifications  with 
Controls  (VwC) 

The  number  of  controls  for  which 
there  is  a  verification  divided  by 
the  number  of  controls  for  all 
hazard  causes 

1 

Design, 

Implementation, 
and  Testing 

9 

Hazard 
Cause/Control 
Closure  Evolution 
(HCCE) 

Three  point  moving  average  of 
the  set  of  open  causes  and 
controls  at  three  consecutive  time 
intervals 

1  or  less.  Greater 
than  1  means  hazard 
causes  or  controls 
are  opening  faster 
than  they  are  closing 

All  activities. 
Design  and 

Implementation 

10 

Software 
Requirements 
Demonstration 
Metric  (SRDM) 

The  total  number  of  demonstrated 
safety  requirements  divided  by 
the  total  number  of  safety 
requirements 

Reasonable  Value 
determined  by  past 
experience 

Testing 

11 

Test  Metrics 

Test  case  criteria  such  as 
statement,  decision,  condition  and 
define -use  pair  and  usage-based 
coverage  and  the  results 

Type  of  test 
coverage  and  a 
successful  test 

Testing 

63 


12 

Key  Node  Safety 

A  metrie  for  predieting  the 

0  to  1 .  The  higher 

Design  and 

Metrie  (S) 

relative  safety  between  different 
versions  of  software  modules 
using  heuristie  analysis  of  fault 
tree  stmeture,  based  on  fault  tree 
properties  sued  as  key  node 
height,  size  of  key  node  sub-trees, 
and  the  number  of  key  nodes 

the  value  the  better 

Implementation 

Table  3.  Software  Safety  Metrics  Ranking  and  Relevance 


G.  REGULATOR  NEEDS 

As  explained  in  Chapter  II,  the  regulator  will  have  significant  influence  on  the 
elements  of  the  framework  and  what  evidence  is  required  for  each.  This  will  depend  on 
the  specific  regulator,  domain  of  operation,  and  the  public  interest  as  most  regulators  are 
independent  public  bodies  established  to  protect  the  public  interest  and  public  safety. 
They  will  exert  influence  and  help  shape  the  specific  requirements  within  each  element  of 
the  framework  as  described  in  this  chapter. 

H.  SUMMARY 

The  framework  described  herein  prescribes  that  in  order  to  successfully 
implement  software  reuse  in  safety-critical  system  of  systems,  organizational  factors 
must  be  supportive,  components  must  be  designed  for  reuse,  those  components 
sufficiently  specified,  and  an  assessment  on  the  environment  suitability  made  before 
deployment.  The  metrics  covered  in  this  chapter  support  the  safety  aspects  of  the 
software  and  those  that  are  related  to  measuring  the  success  of  the  reuse  itself  The 
regulator  will  be  expected  to  further  shape  the  requirements  of  each  section  of  the 
framework  and  specify  the  form  that  evidence  is  to  be  presented  in  and  when. 
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IV.  APPLICATION  OF  THE  FRAMEWORK 


A,  APPLICATION  OF  THE  FRAMEWORK 


For  the  purpose  of  discussing  how  this  framework  may  be  applied,  a  generic 
avionics  software  component  is  chosen  as  the  reusable  software  component  and  the 
safety-critical  system  of  systems  is  the  U.S.  Naval  aviation  system  of  systems.  It  is 
assumed  that  there  is  a  desire  among  stakeholders  to  reuse  this  avionics  software  in  future 
aircraft  systems  or  additional  platforms  within  a  system  of  systems  (as  evident  in  Navy’s 
open  architecture  strategy,  which  among  other  things  seeks  to  enable  component  reuse). 
The  system  of  systems  includes  the  aircraft,  air  traffic  control,  communication  systems, 
naval  vessels  and  bases,  and  the  ground-  and  air-based  systems  of  all  those  elements 
interoperating  with  Naval  aviation  to  achieve  the  common  mission. 


1,  Example  Process  Applying  the  Framework 


Although  the  framework  for  software  reuse  in  safety-critical  system  of  systems  is 
process  neutral,  this  example  application  of  the  framework  will  utilize  a  process  for 
demonstration  purposes  only.  The  framework  is  applied  throughout  the  software  life 
cycle  of  the  reusable  software  component  and  is  shown  in  figure  4. 


Figure  4.  Example  Process  Showing  Application  of  the  Framework 
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When  developing  this  avionies  software  component  and  determining  its 
acceptability  for  reuse  in  the  environment,  the  following  example  approach  may  be 
applied: 

•  Establish  organizational  factors  that  are  supportive  of  reuse  to  ensure  that 
incongruent  organizational  factors  will  not  undermine  a  reuse  approach.  Create 
the  appropriate  organizational  structure  to  manage  the  software  component  and 
a  software  repository  staffed  with  the  appropriate  people  to  manage  it.  Invest 
the  necessary  resources  in  the  reuse  effort  to  ensure  that  the  software 
component  is  suitable  for  reuse  with  significant  stakeholder  support  for  the 
decision  to  design  for  reuse.  Align  organizational  policies  so  that  they 
incentivize  reuse  and  ensure  that  it  is  managed  effectively. 

•  Design  for  reuse  through  the  appropriate  investments  in  quality  and  the 
utilization  of  the  desirable  software  component  attributes  described  in  §3C3. 
Apply  the  software  safety  metrics  described  in  §3F2  to  indicate  progress  in 
designing  in  safety  in  their  respective  order  of  significance  at  the  applicable 
stage  throughout  development  to  indicate  progress  or  achievement  in 
minimizing  the  mishap  risk.  The  software  safety  metrics  are  applied  to  ensure 
that  safety  is  considered  throughout  the  software  development  process. 

•  Specify  and  document  the  software  component  using  the  guidelines  in  §3D2. 

Ensure  that  all  information  on  the  component  remains  with  the  component 

including  the  C^RA  software  component  specification  model  utilizing  an 

appropriate  stakeholder  (including  regulator)  endorsed  ontology  and  the 

respective  software  artifacts  for  the  software  component.  The  specification  of 

the  component  must  facilitate  searching  by  a  respective  future  user  (i.e., 

specification  matching).  That  is,  a  potential  user  must  be  able  to  decide 

whether  the  component  meets  their  requirement  and  provide  more  detailed 

information  once  a  decision  has  been  made  to  investigate  the  component 

further.  The  C^RA  model  should  be  used  as  a  high  level  abstract  description  of 

the  component,  coupled  with  an  appropriate  stakeholder-endorsed  ontology  to 

assist  in  providing  the  information  required  by  future  potential  users  and 
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maintainers  of  the  software  as  it  evolves.  All  software  artifacts  for  the 
component  should  be  properly  documented  in  the  respective  accepted 
languages  and  models  and  provided  with  the  C^RA  model  information. 

•  The  component  should  be  placed  in  the  software  repository  where  that 
information  can  be  easily  accessed,  supported  by  tools,  and  managed  by  the 
appropriate  people  in  accordance  with  policy. 

•  Software  component  information  should  be  made  available  to  the  system  of 
systems  regulator,  to  provide  early  software  component  descriptions  and 
information  that  is  necessary  for  the  regulator  to  be  actively  involved  in  the 
certification  process.  This  information  is  to  be  provided  to  the  regulator 
(certification  authority)  regardless  of  whether  it  has  been  provided  to  the 
applicant,  integrator,  or  user  in  order  to  achieve  certification  for  operation  in 
the  system  of  systems.  The  exact  timings  for  provision  of  this  information  will 
be  dependent  on  the  particular  regulator. 

•  Perform  a  system-of-systems  hazard  analysis  that  incorporates  the  reusable 
software  component.  This  system-of-systems  hazard  analysis  will  include  the 
identification,  analysis,  and  treatment  of  all  system  of  system  hazards  (i.e., 
system  hazards  and  emergent  hazards).  This  analysis  information  will  be  used 
as  input  to  the  safety  case  and  to  update  the  Analysis  element  of  the  C^RA 
model  which  will  subsequently  be  provided  to  the  regulator  as  required. 
Evidence  must  be  obtained  and  captured  that  is  supportive  of  an  acceptable 
level  of  safety  risk  (that  is,  the  safety-critical  system  of  systems  to  contain  the 
component  is  considered  “safe  enough”'^^). 

•  Deploy  the  software  component  in  the  system  of  systems  if  the  system-of- 
systems  hazard  analysis  (environment  match)  is  supportive  of  an  acceptable 
level  of  safety  or  mishap  risk  and  the  regulator  accepts.  Operational 


76  Safe  enough  may  be  defined  as  that  point  where  the  benefits  of  the  system  outweigh  the  risks  to  be 
determined  on  a  case-by-case  basis  by  the  relevant  system  stakeholders. 
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information  is  used  to  constantly  update  to  system-of-systems  hazard  analysis 
to  ensure  an  acceptable  level  of  safety  /  mishap  risk. 

•  Capture  reuse  metrics  throughout  the  software  life  cycle  and  update  the  reuse 
cost-benefit  analysis  in  order  to  measure  the  success  of  the  reuse  program.  This 
will  ensure  that  reuse  performance  is  measured  to  enable  leveraged  success  and 
to  populate  and  update  institutional  memory. 

•  When  the  decision  is  made  to  reuse  the  software  component  (leveraging  off 
that  information  in  the  component  specification)  within  the  existing  system  of 
systems  or  in  another  system  of  systems,  the  safety  analysis  (system-of- 
systems  hazard  analysis)  is  to  be  repeated  with  analysis  information  used  to 
update  the  component  specification  and  subsequently  provided  to  the  regulator. 

B,  CONCLUSION 

To  demonstrate  how  the  framework  may  be  applied,  a  process  was  chosen  and  a 
generic  avionics  software  component  used  as  the  reusable  software  component.  This 
demonstration  provided  an  example  and  discussion  of  how  the  framework  may  be  applied 
to  safety-critical  system  of  systems  where  software  reuse  is  desired. 
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V.  CONCLUSION 


A,  KEY  FINDINGS  AND  ACCOMPLISHMENTS 

Software  reuse  is  viewed  as  a  means  for  aehieving  rapid  system  development, 
saving  resourees  and  time,  and  keeping  up  technologieally  in  an  inereasingly  advancing 
global  environment.  Reuse  offers  many  benefits  and  yet  much  of  the  software  developed 
today  is  still  newly  developed  but  not  unique.  Much  of  the  problem  in  making  software 
reuse  more  prevalent  is  that  software  was  not  designed  with  reuse  in  mind  and  that  not 
enough  readily  available  information  is  shared  on  a  software  component.  Within  a  safety- 
critical  system  of  systems,  the  demand  for  information  on  the  software  components  is 
even  greater  and  more  critical. 

At  present  there  is  very  little  guidance  in  standards  on  how  to  best  utilize  software 
reuse  within  an  industry  or  in  a  system  of  systems.  To  best  utilize  software  reuse,  we 
created  a  framework  to  enable  reuse  within  a  safety-critical  system  of  systems.  That 
framework  consists  of  the  enabler  made  up  of  organizational  factors  and  three  pillars: 
component  attributes  (quality),  component  specification  (information  capture  and  search 
effectiveness),  and  safety  analysis.  Congruence  between  all  framework  elements  is 
required  for  software  reuse  to  be  a  success  in  a  safety-critical  system  of  systems  and  any 
one  element  that  is  not  supportive  may  lead  to  failure.  This  research  focused  on 
developing  the  framework  and  describing  all  elements  required  for  effective  reuse.  In  this 
context  more  information  on  a  software  component  is  required  for  reuse  due  to  the 
complexities  and  potential  system  configurations.  In  essence,  a  system  of  systems  is 
system  reuse  where  existing  systems  are  reused  in  larger  system  configurations  for 
potentially  different  missions. 

This  research  described  the  attributes  of  reusable  software  components,  including 

their  safety-supportive  metrics  and  how  they  should  be  specified,  and  explored  a  process 

for  performing  a  system-of-systems  hazard  analysis.  The  software  component  attributes 

are  based  on  well  accepted  software  engineering  principles  and  those  metrics  that  support 

the  integration  of  system  safety  into  the  design  of  the  software  component.  Software- 
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safety  metrics  were  identified,  ranked  according  to  their  importance,  and  described  by 
their  relevance  in  the  software  life  cycle.  Component  specification  expanded  on  a  set  of 
models  for  describing  components  and  provided  an  abstract  description  of  the  software 
component  for  performing  a  specification  match  as  well  as  including  all  relevant 
information  with  the  component  itself.  The  system-of-systems  hazard  analysis  discussed 
the  environment  match  of  the  software  component  that  must  be  supportive  of  the 
component’s  use  and  be  at  an  acceptable  level  of  mishap  risk  once  treatment  strategies 
have  been  enacted. 

This  research  leveraged  off  other  efforts  to  make  software  reuse  more  prevalent, 
such  as  the  FAA  guidance  on  reusable  software  components  and  the  U.S.  Navy’s  open 
architecture  strategy.  The  FAA  guidance  was  thorough  on  software  reuse  but  focused  on 
collaboration,  communication,  and  product  deliverables  rather  than  a  systematic  approach 
across  the  entire  software  life  cycle. 

A  process  then  decribed  how  the  framework  may  be  applied  to  the  reuse  of  a 
generic  avionics  software  component  within  an  aviation  system  of  systems  context. 

It  is  important  to  realize  that  it  takes  a  concerted  effort  and  commitment  from 
many  people  to  make  software  reuse  a  reality,  especially  in  the  context  of  safety-critical 
system  of  systems.  Organizational  factors  must  support  reuse  across  stakeholders;  the 
software  component  must  be  designed  for  reuse  incorporating  those  principles  and 
properties  that  support  reuse  and  designing  in  of  quality;  the  software  component  must  be 
specified  accordingly  to  provide  the  necessary  information  and  to  facilitate  more 
effective  search  (specification  matching);  and  finally  the  software  component  must  fit  the 
proposed  deployment  environment.  Reuse  should  not  blindly  occur  without  consideration 
of  the  environment  in  which  the  system  will  be  deployed. 

B,  FUTURE  WORK 

One  avenue  of  future  work  is  to  refine  the  specification  model  with  a  fully 
developed  ontology  with  the  aim  of  incorporating  further  precision  into  the  specification 
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and  building  a  better  shared  understanding  by  stakeholders.  This  ontology  is  likely  to  be 
domain  or  system  of  systems  domain  specifie  and  may  require  regulator  and  stakeholder 
endorsement  for  its  suceess. 

Additionally,  future  work  eould  involve  developing  a  ease  study  or  the  testing  of 
the  framework  in  a  system  of  systems  setting  with  the  aim  of  refining  its  applieability  to 
the  safety-eritieal  system  of  systems  domain. 

Further  work  eould  also  inelude  the  development  of  additional  metries  that  deal 
explieitly  with  reuse  eomponents  for  safety-eritieal  system  of  systems. 
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APPENDIX:  EXAMPLE  SOFTWARE  LEVELS  OF  RIGOR 


A,  EXAMPLE  SOFTWARE  LEVEL  OF  RIGOR  (LOR)  MATRIX  AND 
REQUIRED  LEVEL  OF  RIGOR  SOFTWARE  PRODUCTS77 


Hazard 

Severity 

Software  Level  Autonomy 

(1)  Software 

Exercises 

autonomous 

control  over 

potentially 

hazardous 

hardware  systems, 

subsystems  or 

components 

without  the 

possibility  of 

intervention  to 

preclude  the 

occurrence  of  the 

hazardous  event. 

(11a)  Software 

Exercises  control 

over  potentially 

hazardous 

hardware  systems, 

subsystems  or 

components 

allowing  time  for 

intervention  by 

independent 

safety  systems  to 

mitigate  the 

hazard.  However, 

these  systems  by 

themselves  are 

considered  not 

adequate. 

(11b)  Software 

item  displays 

information 

requiring 

immediate 

operator  action  to 

mitigate  a  hazard. 

Software  failures 

will  allow  or  fail 

to  prevent  the 

hazard’s 

occurrence. 

(111a)  Software 

item  issues 

commands  over 

potentially 

hazardous 

hardware 

systems, 

subsystems  or 

components 

requiring 

operator  action 

to  complete  the 

control  function. 

There  are 

several, 

redundant, 

independent 

safety  measures 

for  each 

hazardous  event. 

(111b)  Software 

generates 

information  of  a 

safety  critical  nature 

used  to  make  safety 

critical  decisions. 

There  are  several, 

redundant, 

independent  safety 

measures  for  each 

hazardous  event. 

(IV)  Software 

does  not  control 

safety  critical 

hardware  systems, 

subsystems  or 

components  and 

does  not  provide 

safety  critical 

information. 

Catastrophic 

(I) 

LOR3 

LOR3 

LOR3 

LOR2 

LOR2 

N/A 

Critical 

(11) 

LOR3 

LOR2 

LOR2 

LOR2 

LOR2 

N/A 

Marginal 

(III) 

LOR2 

LOR2 

LOR2 

LORI 

LORI 

N/A 

Negligible 

(IV) 

LORI 

LORI 

LORI 

LORI 

LORI 

N/A 

Table  4.  Example  Software  Level  of  Rigor  Matrix 


77  V.  Basili.,  K.  Dangle.,  L.  Esker.,  F.  Marotta.,  Gaining  Early  Insight  into  Software  Safety:  Measures 
of  Potential  Problems  and  Risks,  in  Proc  of  the  Systems  &  Software  Technology  Conference,  June  2007,  p. 
34. 
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Level  Of  Rigor  (LOR) 

Software  Development  Products 

LOR  3  -  Highest 

Code  Walkthroughs 

Couditiou  /  Decisiou  structural  test  with  safety 

mitigatiou  records 

All  products  iu  lower  levels 

LOR  2 

Desigu  aualysis  with  updates  to  requiremeuts 

hazard  aualysis  products 

Fuuctioual  hazard  aualysis 

Fuuctioual  testiug 

Stress  aud  stability  testiug 

All  products  iu  lower  levels 

LOR  1  -  Lowest 

Software  Safety  Requiremeuts 

Hazard  Mitigatiou  Traceahility  Matrix 

Fuuctioual  or  system  hazard  aualysis 

Hazard  coutrol  Records 

Computer  Program  Chauge  Requests 

System  or  Fuuctioual  Testiug 

Table  5.  Example  Required  Level  of  Rigor  Software  Products 
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B. 


SOFTWARE  RISK  ASSESSMENT  MATRIX  AND  SOFTWARE  HAZARD 
RISK  INDEXES 


Hazard  Severity  Category 

Software  Control  Category 

Catastrophic 

Critical 

Marginal 

Negligible 

I 

1 

1 

3 

5 

H 

1 

2 

4 

5 

HI 

2 

3 

5 

5 

IV 

3 

4 

5 

5 

Table  6.  Software  Risk  Assessment  Matrix 


Hazard  Risk  Index 

Criteria 

1 

High  Risk:  Significant  Analysis  and 

Testing  resources  required. 

2 

Medium  Risk:  Requirements  and  design 
Analysis  and  in-depth  testing  required. 

3-4 

Moderate  Risk:  High  level  analysis  and 
testing  acceptable  with  Managing  Activity 
approval. 

5 

Low  Risk:  Acceptable. 

Table  7.  Software  Hazard  Risk  Index 


78  J.B.  Michael.,  SW4582  Weapon  System  Software  Safety  Lecture  Notes,  Naval  Postgraduate 
School,  2006,  Module  2,  Part  3,  p.  19-20. 
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